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METHOD AND APPARATUS FOR ORDERING GOODS, SERVICES AND 
CONTENT OVER AN INTERNETWORK USING A VIRTUAL PAYMENT 

ACCOUNT 
Cross-Reference to Related Applications 
This application is a Continuation-ln-Part of prior United States Application 
No. 09/140,949, filed August 9, 1999, priority from the filing dale of which is hereby 
claimed under 35 U.S.C. § 120. This application also claims the benefit of 
Provisional Application No. 60/140,039, filed June 18, 1999, the benefit of which is 
hereby claimed under 35 U.S.C. § 119. 

Field of the Invention 
This invention generally relates to a method and apparatus for ordering goods, 
services and content from one or more other computers connected via common 
communications links and, more particularly, to a method and apparatus for ordering 
goods, services and content from computers connected to the Internet using a virtual 
payment account. 

Background of the Invention 
Communication networks are well known in the computer communications 
field. By definition, a network is a group of computers and associated devices that 
are connected by communications facilities or links. Network communications can 
be of a permanent nature, such as via cables, or can be of a temporary nature, such as 
connections made through telephone or radio links. Networks may vary in size, from 
a local area network (LAN) consisting of a few computers or workstations and related 
devices; to a wide area network (WAN) which interconnects computers and LANs 
that are geographically dispersed; to a remote access service (RAS) which 
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interconnects remote computers via temporary communication links. An 
internetwork, in turn, is the joining of multiple computer networks, both similar and 
dissimilar, by means of gateways or routers that facilitate data transfer and 
conversion from various networks. A well-known abbreviation for the term 
5 internetwork is "Internet." As currently understood, the capitalized term "Internet" 
refers to the collection of networks and routers that use the Transmission Control 
Protocol/Internet Protocol (TCP/IP) to communicate with one another. 

A representative section of the Internet 40 is shown in FIGURE 1 (Prior Art) 
in which a plurality of local area networks (LANs) 44 and a wide area network 
10 (WAN) 46 are interconnected by routers 42. The routers 42 are generally special 
purpose computers used to interface one LAN or WAN to another. Communication 
links within the LANs may be twisted wire pair, or coaxial cable, while 
communication links between networks may utilize 56 Kbps analog telephone lines, 
or 1 Mbps digital T-l lines and/or 45 Mbps T-3 lines. Further, computers and other 
1 5 related electronic devices can be remotely connected to either the LANs 44 or the 
WAN 46 via a modem and temporary telephone link. Such computers and electronic 
devices 48 are shown in FIGURE 1 as connected to one of the LANs 44 by a dotted 
line. It will be appreciated that the Internet comprises a vast number of such 
interconnected networks, computers and routers and that only a small, representative 
20 section of the Internet 40 is shown in FIGURE 1 . 

The Internet has recently seen explosive growth by virtue of its ability to link 
computers located throughout the world. As the Internet has grown, so has the World 
Wide Web (WWW). The WWW is a vast collection of interconnected or "hypertext" 
documents (also known as "Web pages") written in HyperText Markup Language 
25 (HTML) that are electronically stored at "Web sites" throughout the Internet. A Web 
site is a server connected to the Internet that has mass storage facilities for storing 
hypertext documents and that runs administrative software for handling requests for 
those stored hypertext documents. A hypertext document normally includes a 
number of hyperlinks, i.e., highlighted portions of text that link the document to 
30 another hypertext document possibly stored at a Web site elsewhere on the Internet. 
Each hyperlink is associated with a Uniform Resource Locator (URL) that provides 
the exact location of the linked document on a server connected to the Internet. Thus, 
whenever a hypertext document is retrieved from any Web server, the document is 
considered to be retrieved from the WWW. 



WO 00/79452 



-3- 



PCT/US00/16669 



A user is allowed to retrieve hypertext documents from the WWW, i.e., a user 
is allowed to "surf the Web," via a Web browser. A Web browser, such as 
NETSCAPE NAVIGATOR® or MICROSOFT® Internet Explorer, is a software 
program implemented by a Web client, i.e., a user's computer, to provide a graphical 
user interface to the WWW. Upon request from the user via the Web browser, the 
Web client accesses and retrieves the desired hypertext document or Web page from 
the appropriate Web server using the URL for the document and a protocol known as 
HyperText Transfer Protocol (HTTP). HTTP is a higher-level protocol than TCP/IP 
and is designed specifically for the requirements of the WWW. It is used on top of 
TCP/IP to transfer hypertext documents between servers and clients. 

At the advent of the WWW, the information stored on the Internet was freely 
transferred back and forth between those parties interested in the information. 
However, the WWW is quickly becoming a channel of commercial activity, whereby 
a vast number of companies have developed their own Web sites for advertising and 
selling their goods and services. Commercial activity that takes place by means of 
connected computers is known as electronic commerce, or e-commerce, and can 
occur between a buyer and a seller through an on-line information service, the 
Internet, a bulletin board system (BBS), or between buyer and seller computers 
through electronic data interchange (EDI). A buyer (also referred to as a user, 
consumer or purchaser in the context of e-commerce) may "visit the Web site" of a 
company or seller, i.e., retrieve the hypertext documents located on the Web server of 
a particular seller, and order any good or service that the seller has to offer. If that 
good or service is in the form of electronically stored information, such as a book, a 
video, a computer game, etc., the buyer may simply download the good or service 
from the company's Web site to his or her computer for immediate consumption and 
use. If the good or service is of a more tangible nature, such as an appliance or article 
of clothing ordered from an on-line catalog, a more conventional method of delivery, 
e.g., the postal service or a common carrier, is used. 

A common method of payment for e-commerce purchases is electronic credit, 
or e-credit. E-credit is a form of electronic commerce often involving credit card 
transactions carried out over the Internet. Traditional e-credit purchases are paid for 
by a major credit card, wherein the buyer is required to transmit his or her credit 
information, for example, an account number and expiration date, over the Internet to 
the company's Web site. Many buyers are concerned about the security and 
confidentiality of such electronic transmissions. Furthermore, many buyers do not 
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have a major credit card with which to make such purchases. Alternative billing 
systems, such as providing credit information by facsimile or postal service, are much 
less convenient and often prove enough of a barrier to prohibit the sale altogether. 
Finally, the traditional methods of billing and payment do not adequately protect the 
seller or buyer from fraudulent purchases. 

Accordingly, a more effective method and apparatus for ordering and billing 
for goods, services and content over a network, and ultimately the Internet, is needed. 
The method and apparatus should protect the seller and buyer from fraudulent 
purchases. Additionally, the method and apparatus should provide an element of 
non-repudiation to all transactions. The method and apparatus should also prevent 
buyers with histories of nonpayment from purchasing additional goods, services 
and/or content. Finally, the method and apparatus should allow a buyer without a 
major credit card to purchase goods, services and content over the network. 

Summary of the Invention 

The present invention provides a computer program for ordering products 
from computers connected to the Internet, wherein the buyer is automatically billed 
for the ordered good, service or content based on a virtual payment account 
maintained by a commerce gateway. 

In accordance with other aspects of the present invention, a commerce 
gateway interfaces with a credit processing server to handle the monetary aspects 
involved in purchasing goods, services and/or content. The credit processing server 
interfaces with one or more financial institutions that physically handle the buyer's 
account. For example, a buyer can pay for purchases electronically by transferring 
funds from a bank account held by the buyer at a financial institution, or by prepaying 
for the purchases by sending a check to the provider of the commerce gateway. 
Alternatively, reward points earned by using the virtual payment account can be 
applied towards purchases. 

In accordance with still other aspects of the present invention, the credit 
processing server or commerce gateway communicates with one or more identity 
bureaus in order to determine a buyers identity before creating a virtual payment 
account. 

In accordance with still other aspects of the present invention, the credit 
processing server communicates with one or more credit bureaus in order to 
determine a credit limit for a buyer's virtual payment account. 
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Id accordance with yet other aspects of the present invention, a virtual 
payment account can have associated sub-accounts. A sub-account can have a credit 
iimit that is less than the main account credit limit. A sub-account can limit the seller 
sites from which goods, services and/or content can be purchased. 

In accordance with further aspects of the present invention, purchases must be 
made by a registered buyer from a registered seller. Security is ensured via 
authentication of the parties to a transaction. Authentication can be performed by 
verification of a digital certificate, or a digital signature, or by alternate authentication 
methods. 

Brief Description of the Drawing s 
The foregoing aspects and many of the attendant advantages of this invention 
will become more readily appreciated as the same become better understood by 
reference to the following detailed description, when taken in conjunction with the 
accompanying drawings, wherein: 

FIGURE 1 (Prior Art) is a block diagram of a representative portion of the 
Internet; 

FIGURE 2 is a pictorial diagram of a local area network (LAN) connected to 
the Internet which supplies goods, services and/or content ordered by a buyer using a 
computer located elsewhere on the Internet in accordance with the present invention; 

FIGURE 3 is a block diagram of the several components of the buyer's 
computer shown in FIGURE 2 that is used to order goods, services and/or content 
from the Internet in accordance with the present invention; 

FIGURE 4 is a block diagram of the several components of a seller server 
shown in FIGURE 2 that provides the ordered goods, services and/or content in 
accordance with the present invention; 

FIGURE 5 is a block diagram of the several components of a commerce 
gateway shown in FIGURE 2 that is used to interface between the Internet and a 
credit processing server in accordance with the present invention; 

FIGURE 6 is a block diagram of the several components of a credit 
processing server shown in FIGURE 2 that provides for the payment of the ordered 
goods, services and/or content in accordance with the present invention; 

FIGURE 7 is a diagram illustrating the actions taken by a buyer's computer, 
the commerce gateway, the credit processing server, an identity bureau and a credit 
bureau to create a virtual payment account for a buyer; 
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F1GURES 8A-8G are exemplary Web pages displayed on a buyer's computer 
when applying for a virtual payment account in accordance with the present 
invention; 

FIGURES 9A-9C are exemplary Web pages used by a buyer to customize the 
5 virtual payment account applied for in accordance with the present invention; 

FIGURES 1 OA- IOC are exemplary Web pages displayed on a buyer's 
computer containing account statements and reports for a buyer's virtual payment 
account in accordance with the present invention; 

FIGURES 11 A- HE are exemplary Web pages used by a buyer to purchase 
10 goods, services and/or content in accordance with the present invention; 

FIGURE 12 is a flow diagram illustrating the logic used by the buyer's 
computer to order goods, services and/or content from the Internet using the Web 
browser; 

FIGURE 13 is a flow diagram illustrating the logic used by a buyer 
15 authenticator of the buyer's computer to validate that the buyer is a registered virtual 
payment account participant; 

FIGURE 14 is a flow diagram illustrating the logic used by an alternate buyer 
authenticator of the buyer's computer to validate that the buyer is a registered virtual 
payment account participant; 
20 FIGURE 15 is a flow diagram illustrating the logic used by the buyer's 

computer to apply for a virtual payment account using the Web browser; 

FIGURE 16 is a flow diagram illustrating the logic used by an enrollment 
server of the commerce gateway shown in FIGURE 5 to establish a new buyer 
account in accordance with the present invention; 
25 FIGURE 17 a flow diagram illustrating the logic used by an account 

identification container generator of the commerce gateway shown in FIGURE 5 to 
generate an account identification for a given transaction; 

FIGURE 1 8 is a flow diagram illustrating the logic used by a commerce 
engine of a seller computer shown in FIGURE 4 to provide for the ordering, shipment 
30 and payment of goods, services and/or content over the Internet; 

FIGURE 19 is a flow diagram illustrating the logic used by a commerce 
gateway adapter of the seller server shown in FIGURE 4 to allow a commerce engine 
to communicate with a transaction server on the commerce gateway; 
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FIGURE 20 is a flow diagram illustrating the logic used by the transaction 
server of the commerce gateway shown in FIGURE 5 to process an order for goods, 
services and/or content over the Internet using a virtual payment account; 

FIGURES 21 and 22 are flow diagrams illustrating the logic used by various 
sub-systems of the credit processing server shown FIGURE 6 to provide for payment 
of goods, services and/or content ordered over the Internet using a virtual payment 
account; 

FIGURE 23 is a diagram illustrating the actions taken by the buyer's 
computer, the seller server and the commerce gateway to order goods, services and/or 
content using the virtual payment account; 

FIGURE 24 is a flow diagram illustrating the logic used by the seller's 
computer to perform a settlement transaction, i.e., initiate transfer of funds; 

FIGURE 25 is a flow diagram illustrating the logic used by the transaction 
server of the commerce gateway shown in FIGURE 5 to process a settlement 
transaction; 

FIGURE 26 is a flow diagram illustrating the logic used by the 
administrators computer to initiate a refund to be applied to a virtual payment 
account in accordance with the present invention; 

FIGURE 27 is a flow diagram illustrating the logic used by a commerce 
gateway to process a request for information from an identity bureau; 

FIGURE 28 is an exemplary window of an e-mail computer program 
containing an alternate authentication message; 

FIGURE 29 is a pictorial diagram of an exemplary device showing an 
alternate authentication message; 

FIGURE 30 is an exemplary Web page showing an alternate authentication 

dialog; 

FIGURES 31-41 are exemplary Web pages used by a seller to view 
transactions, status of payments and reports; 

FIGURE 42 is a flow diagram illustrating the logic used to authenticate a 
seller and generate a report for seller. 

Detailed Description of the Preferred Embodiment 

As previously described and shown in FIGURE 1, the Internet 40 is a 
collection of local area networks (LANs) 44, wide area networks (WANs) 46, remote 
computers 48 and routers 42 that use the Transmission Control Protocol/Internet 
Protocol (TCP/IP) to communicate with each other. The World Wide Web (WWW), 
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on the other hand, is a vast collection of interconnected, electronically stored 
information located on servers connected throughout the Internet 40. Many 
companies are now selling goods, services and access to their premium content over 
the Internet using the WWW. In accordance with the present invention, a buyer 
orders goods, services and/or content (referred to interchangeably herein as 
"products") over the Internet 40 via a Web browser and is automatically billed for the 
purchase using his or her virtual payment account without transferring sensitive 
account information, such as account number and expiration date, over the 
Internet 40. The virtual payment account allows a buyer to settle transactions of the 
virtual payment account using a prepaid or credit account. In one actual embodiment 
of the present invention, the virtual payment account uses bank electronic funds 
transfers, for example, using the Automated Clearing House (ACH) standard which is 
maintained by the National Automated Clearing House Association (NACHA) - the 
standards group promoting electronic commerce standards. In another embodiment, 
the virtual payment account can be funded using a traditional paper check, with the 
buyer mailing a check, e.g., via the postal service, to the providers of the virtual 
payment account system. Alternatively, funds transfer services and electronic bill 
payment services, such as CHECKFREE®, may be used. Reward points earned 
through use of the virtual payment account can also be applied to the buyer's virtual 
payment account to pay for products. 

More specifically, as shown in FIGURE 2, the buyer purchases goods, 
services, and/or premium content from a seller server 51, i.e., a computer owned by 
the seller which sponsors or sells the product, by placing an order with the seller 
server from a computer 50 connected to the Internet 40. The order is processed and 
confirmed by a commerce gateway 52 connected to a LAN 44 located elsewhere in 
the Internet 40. The commerce gateway 52 is also connected to a credit processing 
server 53 via the LAN 44. The credit processing server 53 communicates with one or 
more identity bureaus 56 to verify the identity of the buyer. After verifying the 
identity of the buyer the credit processing server 53 communicates with one or more 
credit bureaus 58 in order to determine the credit worthiness of a buyer. 

In one actual embodiment of the present invention described herein, the 
identity bureau 56 is a server provided and maintained by an agency for verifying the 
identity of the buyer and the credit bureau 58 is a server provided and administrated 
by a credit agency for processing credit reports for buyers. The identity bureau 56 
and credit bureau 58 can be located on the LAN 44 or elsewhere on the Internet 40. 
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ln yet another embodiment, the credit processing server can establish a point- 
to-point connection with a remote identity bureau or credit bureau that is not 
connected to either the LAN 44 nor the Internet 40. It will be appreciated that other 
methods of communication between the credit processing server 53 and identity 
bureau 56 or credit bureau 58 may be used, for example, a secure Virtual Private 
Network (VPN) maintained and operated by the identity bureau or credit bureau 
exclusively for the purpose of identity checking or credit rating, respectively. 

Finally, in yet other embodiments, the identity and credit bureaus may not 
actually offer a server at all. Rather, a customer service representative for the identity 
or credit bureaus may process the identity or credit report and manually provide the 
report to an administrator of the present invention who manually enters the report to 
the credit processing server 53. 

The credit processing server 53 also communicates with one or more financial 
institutions 59 for the purpose of obtaining the buyer's payment, i.e., a transfer of 
funds for the purchase of products. As is the case with the identity and credit 
bureaus 58, the financial institutions 59 may be other servers in electronic 
communication with the credit processing server 53, customer service representatives 
in more traditional communication with the credit processing server 53, or some 
combination thereof. 

Finally, in addition to the commerce gateway 52, the LAN 44 includes an 
administrative computer 54 used to administer buyer and seller information and 
services provided by the commerce gateway 52 and credit processing server 53. 

In the exemplary embodiment of the present invention shown in FIGURE 2, 
the LAN 44 is insulated from the Internet 40 by a firewall 55 that tracks and controls 
the flow of all data passing through it. The firewall 55 protects the LAN 44 from 
malicious in-bound data traffic. The LAN 44 is a bus network interconnecting the 
various computers and servers. The LAN 44 shown in FIGURE 2 can be formed of 
various coupling media such as glass or plastic fiber-optic cables, coaxial cables, 
twisted wire pair cables, ribbon cables, etc. In addition, one of ordinary skill in the 
art will appreciate that the coupling medium can also include a radio frequency 
coupling media or other intangible coupling media. Any computer system or number 
of computer systems, including but not limited to workstations, personal computers, 
laptop computers, personal data assistants, servers, remote computers, etc., that is 
equipped with the necessary interface hardware may be connected temporarily or 
permanently to the LAN 44, and thus, the Internet 40. However, if temporarily 
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connected via a telephone link to another device connected to the LAN 44, the 
interface hardware of both the remote computer 48 and the device to which it is 
connected must contain a modem. 

Also shown in FIGURE 2 is an exemplary authentication device 205 whose 
purpose will be described in more detail below. In one embodiment of the current 
invention, the authentication device may be a personal data assistant (PDA) with a 
wireless modem. However, those of ordinary skill in the art will appreciate that the 
authentication device may be a laptop computer, a cellular telephone, a pager or any 
device capable of receiving a remote message. 

Finally, those of ordinary skill in the art will recognize that while only one 
buyer computer 50, and one seller server 51 are depicted in FIGURE 2, numerous 
buyer computers and seller servers equipped with the hardware and software 
components described below may be connected to the Internet 40. It will also be 
appreciated that the term "buyer" used herein can be applied to any purchaser of 
goods and/or services and can be applied equally to an individual, non-commercial 
purchaser, a business or a commercial purchaser. In other words, the term "buyer" 
can apply to any purchaser and the term "seller" can apply to any vendor or merchant, 
be they on individual, non-commercial seller, a business or a commercial seller. 
Relevant Buyer Compu ter, Seller Server, Commerce Gateway, and Credit Processing 

Server Components 
FIGURE 3 depicts several of the important components of the buyer's 
computer 50. Those of ordinary skill in the art will appreciate that the buyer's 
computer 50 could be any computer used by the buyer to utilize the buyer's virtual 
payment account Additionally, those of ordinary skill in the art will appreciate that 
the buyer's computer 50 may include many more components then those shown in 
FIGURE 3. However, it is not necessary that all of these generally conventional 
components be shown in order to disclose an illustrative embodiment for practicing 
the present invention. As shown in FIGURE 3, the buyer's computer includes a 
network interface 60 for connecting to a LAN 44 or WAN 46, or for connecting 
remotely to a LAN or WAN. Those of ordinary skill in the art will appreciate that the 
network interface 60 includes the necessary circuitry for such a connection, and is . 
also constructed for use with the TCP/IP protocol, the particular network 
configuration of the LAN or WAN it is connecting to, and a particular type of 
coupling medium. 
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The buyer's computer 50 also includes a processing unit 61 , a display 62 and a 
memory 63. The memory 63 generally comprises a random access memory (RAM), 
a read-only memory (ROM) and a permanent mass storage device, such as a disk 
drive. The memory 63 stores the program code and data necessary for ordering and 
5 paying for a product over the Internet 40 in accordance with the present invention. 
More specifically, the memory 63 stores a Web browser component 64, such as 
NETSCAPE NAVIGATOR® or MICROSOFT® Internet Explorer, and a buyer 
authenticator component 65 formed in accordance with the present invention for 
authenticating a buyer as a registered participant of the virtual payment system prior 
10 to performing any virtual payment account transactions. It will be appreciated that 
these components may be stored on a computer-readable medium and loaded into 
memory 63 of the buyer computer 50 using a drive mechanism associated with the 
computer-readable medium, such as a floppy or DVD/CD-ROM drive. 

As will be described in more detail below, the products ordered by the buyer 
15 are supplied by a seller server 51, described next, following authorization from a 
remote server, i.e., a commerce gateway 52 described later, located elsewhere on the 
Internet, e.g., on LAN 44 illustrated in FIGURE 2. FIGURE 4 depicts several of the 
important components of the seller server 51. Those of ordinary skill in the art will 
appreciate that the seller server 51 includes many more components than those shown 
20 in FIGURE 4. However, it is not necessary that all of these generally conventional 
components be shown in order to disclose an illustrative embodiment of practicing 
the present invention. As shown in FIGURE 4, the seller server 51 includes a 
network interface 70 for connecting to a LAN 44 or WAN 46, or for connecting 
remotely to a LAN or WAN. Those of ordinary skill in the art will appreciate that the 
25 network interface 70 includes the necessary circuitry for such a connection, and is 
also constructed for use with the TCP/IP protocol, the particular network 
configuration of the LAN or WAN it is connecting to, and a particular type of 
coupling medium. 

The seller server 51 also includes a processing unit 71, a display 72 and a 
30 memory 73. The memory 73 generally comprises a random access memory (RAM), 
read-only memory (ROM), and a permanent mass storage device, such as a hard disk 
drive, tape drive, optical drive, floppy disk drive, or combination thereof In one 
actual embodiment of the present invention, the memory contains a product 
database 74 that includes the electronically stored good or service ordered by the 
35 buyer. In other embodiments of the present invention, the product database 74 stores 
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Ihe premium content ordered by the buyer, i.e., the hypertext documents or other 
electronically stored information considered of monetary value by the seller. In yet 
other embodiments of the present invention, the goods may be tangible goods not 
capable of being electronically stored, in which case the product database includes 

5 descriptive information of the products. 

The memory 73 also contains a commerce engine component 75 for 
purchasing a product from a seller Web site. The commerce engine component 75 
may be an existing commerce engine, such as MICROSOFT® Site Server, which 
allows for the payment of products ordered over the Internet using a major credit 

10 card, e.g., VISA® or MASTERCARD®. A commerce gateway adapter 
component 76 is also provided to allow the commerce engine component 75 to 
interface with the commerce gateway 52. The commerce gateway adapter component 
uses and provides application programming interface (API) calls to interface with the 
commerce engine 75. Also included in memory is a seller authenticator 

15 component 77 for verifying that the seller is an authorized or registered seller of the 
virtual payment system of the present invention. It will be appreciated that the 
product database 74, the commerce engine component 75, the commerce gateway 
adapter component 76 and the seller authenticator component 77 may be stored on a 
computer-readable medium and loaded into memory 73 of the seller server 51 using a 

20 drive mechanism associated with the computer-readable medium, such as a floppy or 
CD-ROM drive. Finally, memory 73 stores a Web server component 78 for handling 
requests for stored information received via the Internet and the WWW. 

FIGURE 5 depicts several of the important components of the commerce 
gateway 52. Those of ordinary skill in the art will appreciate that the commerce 

25 gateway 52 includes many more components than those shown in FIGURE 5. 
However, it is not necessary that all of these generally conventional components be 
shown in order to disclose an illustrative embodiment for practicing the present 
invention. As shown in FIGURE 5, the commerce gateway 52 is connected to the 
LAN 44 via a network interface 80. Those of ordinary skill in the art will appreciate 

30 that the network interface 80 includes the necessary circuitry for connecting the 
commerce gateway 52 to the LAN 44 and the firewall 55, and is constructed for use 
with the TCP/IP protocol, the particular network configuration of the LAN 44, and 
the particular type of coupling medium. 

The commerce gateway 52 also includes a processing unit 81, a display 82 

35 and a memory 83. The memory 83 generally comprises a random access memory 
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(RAM), a read-only memory (ROM), and a permanent mass storage device, such as a 
hard disk drive, tape drive, optical drive, floppy disk drive, or combination thereof. 
The memory 83 stores the program code and data necessary for authorizing a seller 
server 51 to supply products to buyers and obtaining payment for the products via a 
credit processing server 53 in accordance with the present invention. More 
specifically, the memory 83 stores a transaction server component 84 formed in 
accordance with the present invention for authorizing a seller to supply the ordered 
product and obtaining payment for the ordered product from the credit processing 
server 53. Memory 83 also contains an identity bureau adapter 79 formed in 
accordance with the present invention for verifying a buyer or seller's identity. Also 
stored in memory 83 is an enrollment server component 89 formed in accordance 
with the present invention for determining the credit worthiness of an applicant. An 
account identification container generator component 88 is also stored in memory 83 
for determining an internal account identification. A report server 85 is also stored in 
memory 83 for processing request for reports and consolidating information for 
requested reports. Also stored in the memory 83 is a credit processing server adapter 
component 86 for communicating with a credit processing server 53 described below. 
It will be appreciated that the transaction server component 84, the credit processing 
server adapter component 86, the account identification container generator 
component 88, and the enrollment server component 89 may be stored on a 
computer-readable medium and loaded into memory 83 of the commerce gateway 52 
using a drive mechanism associated with the computer-readable medium, such as 
floppy or CD-ROM drive. The memory 83 also stores a Web server component 87 
for handling requests for stored information received via the Internet 40 and the 
WWW. 

FIGURE 6 depicts several of the important components of the credit 
processing server 53. Those of ordinary skill in the art will appreciate that the credit 
processing server 53 includes many more components than those shown in 
FIGURE 6. However, it is not necessary that all of these generally conventional 
components be shown in order to disclose an illustrative embodiment for practicing 
the present invention. As shown in FIGURE 6, the credit processing server 53 is 
connected to the LAN 44 via a network interface 90. Those of ordinary skill in the 
art will appreciate that the network interface 90 includes the necessary circuitry for 
connecting the credit processing server 53 to the LAN 44 and the firewall 55, and is 
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constructed for use with the TCP/IP protocol, the particular network configuration of 
the LAN 44, and the particular type of coupling medium. 

The credit processing server 53 also includes a processing unit 91, a 
display 92 and a memory 93. The memory 93 generally comprises a random access 
memory (RAM), a read-only memory (ROM), and a permanent mass storage device, 
such as a hard disk drive, tape drive, optical drive, floppy disk drive, or combination 
thereof The memory 93 stores the program code and data necessary for authorizing 
and securing payment for products purchased using a virtual payment account in 
accordance with the present invention. More specifically, the memory 93. of the 
credit processing server stores credit processing sub-systems including: an 
account/billing sub-system 94 for billing a buyer for products purchased using a 
virtual payment account; a payment processing sub-system 95 for communicating 
with a financial institution 59 in order to process payments received for purchases 
made using a virtual payment account; and an account enrollment sub-system 96 for 
determining the credit limit for an applicant as determined by information received 
from one or more credit bureaus 58. 

Also stored in memory 93 are an account database 97 and a financial 
database 98 used to store data required for the account/billing sub-system 94, the 
payment processing sub-system 95, identity bureau adapter 99 and the account 
enrollment sub-system 96 to perform their required functions. It will be appreciated 
that the account/billing sub-system 94, the payment processing sub-system 95, the 
account enrollment sub-system 96, the account database 97, identity bureau adapter 
99 and the financial database 98 may be stored on a computer-readable medium and 
loaded into memory 93 of the credit processing system using a drive mechanism 
associated with the computer-readable medium, such as floppy or DVD/CD-ROM 
drive. It will also be appreciated that the account/billing sub-system 94, the payment 
processing sub-system 95, and the account enrollment sub-system 96 can comprise, 
either in full or in part, existing, traditional credit card payment systems. 

FIGURES 3-6 depict important components of the buyer computer 50, seller 
server 51, commerce gateway 52 and credit processing server 53 shown in FIGURE 2 
of one embodiment of the present invention. It will be appreciated that many other 
implementations and variations are possible. For example, one or more of the credit 
processing sub-systems 94, 95, 96 could be included in the commerce gateway 52 
instead of in the credit processing server 53. Alternatively, each of the credit 
processing sub-systems 94, 95, 96 of the credit processing server could be in a 
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separate server. Further, additional commerce gateways 52 and credit processing 
servers 53 may be located on the LAN 44 or elsewhere on the Internet 40. 

Applying for a Virtual Payment Account 
Once a virtual payment account is set up, the virtual payment system of the 
present invention is a closed system that provides buyers a secure method for 
purchasing products over the Internet. The closed system includes only a registered 
buyer's computer '50, a registered seller server 51, the commerce gateway 52 
(administered by the provider of the virtual payment system) and the credit 
processing server 53 (which can also be administered by the provider of the. virtual 
payment system). Since the account information necessary for charging the buyer for 
the purchase is already in the possession of the commerce gateway 52 and the credit 
processing server 53, the closed system of the present invention allows registered 
buyers to purchase products from registered sellers without transferring sensitive 
account information to the sellers over the Internet. In order to become a member of 
the virtual payment system of the present invention, a buyer becomes a registered 
user by obtaining a virtual payment account. FIGURE 7 illustrates the actions taken 
by the buyer's computer 50, the commerce gateway 52, the credit processing 
system 53, and the credit bureau 58 to create a virtual payment account for a buyer. 
The interactions of the various components are illustrated and described in detail later 
for various transactions performed by the present invention with reference to the 
diagrams shown in FIGURES 12, 27 and 42. As shown in FIGURE 7, the process of 
applying for a virtual payment account is initiated when a buyer requests 100 an 
application form via the Internet using the Web browser 64 installed on the buyer's 
computer 50. The buyer may apply for a virtual payment account directly from a 
virtual payment account Web site located at the commerce gateway 52 or indirectly 
from a registered seller site located at the seller server 5 1 . Once the request 100 for 
the application form is received by the commerce gateway 52, the commerce 
gateway 52 provides buyer computer 50 the application form 102 so that the buyer 
can complete the form displayed in the Web browser 64 of the buyer computer 50. 

Upon completion of the application form, the buyer computer 50 submits the 
completed application form 104 to the commerce gateway 52. The commerce 
gateway 52 then submits the application data 1 06 from the completed form to the 
credit processing server 53 for account and credit limit authorization. The credit 
processing server 53 verifies the application data by requesting identity 
information 1 16 from an identity bureau 56. The identity bureau provides the 
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requested identity information 118 and if the provided identity information 
corresponds to the application data then the credit processing server 53 requests 
credit information 108 about the buyer from a credit bureau 58. However, in one 
actual embodiment of the present invention, if the application data does not conform 
to the identity information from the identity bureau 56, then no virtual payment 
account is created and the application is forwarded to customer service for review for 
possible fraud detection. As noted above, in the actual embodiment of the present 
invention, the identity bureau 56 is a server provided and maintained by an agency for 
verifying identity and the credit bureau 58 is a server provided and administrated by a 
credit agency for processing credit reports. Hence, the credit processing server 53 
requests the desired identity and credit information electronically, e.g., via 
appropriate database queries, etc., from the identity bureau 56 and credit bureau 58. 

Returning to the illustrated embodiment/the credit bureau 58 provides the 
requested credit information 1 10 to the credit processing server 53 via the connection 
with the credit processing server 53. The credit processing server 53 then evaluates 
the application, identity and credit information by combining the identity information 
from the identity bureau and the credit information received from the credit bureau 58 
with application data in order to determine a credit score 111. If the score exceeds a 
certain threshold, a credit limit is set and the virtual payment account is created 1 1 2. 
If the score falls below the threshold, a virtual payment account may still be 
created 112, however, all purchases must be prepaid, and the account information is 
forwarded to a customer service representative for review for a possible later grant of 
credit. 

Once the virtual payment account is created, the credit processing server 53 
returns the result of the evaluation 1 13, e.g., approval/denial, prepaid account only, 
credit limit, etc., to the commerce gateway 52. The commerce gateway then 
requests 120 that the buyer authenticator 65 on the buyer computer generate a public 
key encryption key pair 122 comprising a secret key and a public key. The buyer 
authenticator 65 then submits the public key to the commerce gateway 1 24. The 
commerce gateway 52 digitally signs the public key to generate a digital 
certificate 126. As will be appreciated by those of ordinary skill in the art, a digital 
certificate comprises a public key digitally signed by a trustworthy entity. The 
commerce gateway 52 sends the digital certificate and an application result page 114 
to the buyer computer 50 for display via the buyer computer's Web browser 64. 



WO 00/79452 



PCT/US00/I6669 



-17- 



10 



15 



20 



25 



30 



35 



Finally, the buyer computer stores the digital certificate 128 for use later with the 
virtual payment account. 

It will be appreciated that the digital certificate may be stored in the 
memory 63 of the buyer computer 50, or on some form of device capable of 
interfacing with the buyer computer such as but not limited to a secure token, smart 
card or as an encrypted file on some other computer readable medium. It will be 
appreciated by those of ordinary skill in the art that the order of the operations in 
FIGURE 7 may be altered without substantially affecting the operation of the present 
invention. For example, the buyer may be notified of the application results, before 
generating the public key encryption pairs. 

FIGURES 8A-8G are exemplary Web pages provided to the buyer by the 
Web browser 64 of the buyer computer 50 in connection with applying for a virtual 
payment account as described above. Using the Web page 600 shown in 
FIGURE 8 A, the buyer selects the type of virtual payment account they desire to 
apply for, e.g., credit or prepaid, and submits the information by clicking "continue." 
Next, the Web pages 605, 610 and 615 shown in FIGURES 8B-8D for the application 
form are displayed to the buyer via the Web browser 64. In one actual embodiment 
of the present invention, the buyer fills out the application form with the appropriate 
application data on-line. Alternatively, the buyer can request the application on a 
printed form and submit the printed form via facsimile or regular mail, in which case 
a customer service representative will enter the information into the account 
database 97 of the credit processing server 53 via the administrative user 
computer 54. The application data includes information such as social security 
number and income that will be used to determine a credit limit for the buyer. 
Information entered by the buyer in the application form is also used for demographic 
purposes. For example, banner advertisements can be displayed via the Web 
browser 64 on the buyer computer 50 and can be targeted to the buyer based on 
demographic information, such as the buyer's age and geographic location. 

After the buyer completes the application form contained in the Web pages, 
605, 610 and 615 shown in FIGURES 8B-8D and the application is processed by the 
credit processing server 53, a Web page 620 as shown in FIGURE 8E is transferred 
to and displayed by the buyer computer's Web browser 64, which notifies the buyer 
of the results of the application process, i.e., account approval and details of his or 
her virtual payment account, including the account credit limit. Once the account 
approval is complete and the account accepted by the buyer, the commerce 
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gateway 52 then transmits the buyer authenticator component 65 (which, as described 
above, generates a public key encryption key pair) to the buyers computer for 
installation as shown in FIGURE 8F. FIGURE 8G shows an exemplary Web 
page 630 that allows the buyer to activate their virtual payment account. 

Customizing and Modifying a Virtua l Payment Account 
Once a virtual payment account has been approved and a credit limit set as 
described above, the account can be customized by the buyer. Account information 
is then stored in the account database 97 of the credit processing server 53. 
FIGURES 9A-9C illustrate an exemplary set of Web pages downloaded from the 
commerce gateway 52 and displayed by the Web browser 64 of the buyer's 
computer 50 for customizing the buyer's virtual payment account. FIGURES 9A-9B 
illustrate Web pages 640 and 645 for main account customization. As shown in 
FIGURE 9A, the buyer may customize his or her virtual payment account contact 
information and preferences. FIGURE 9B illustrates that the main account holder is 
able to configure access controls for their account and all sub-accounts as shown in 
Web page 645. 

As shown in FIGURE 9C, the buyer may also customize sub-accounts for his 
or her own use, or for use by a business partner, spouse and/or children. As will be 
described in more detail below, the buyer may then impose his or her own spending 
limits on the sub-accounts. In one actual embodiment, reward points accrue in the 
main account so that the buyer can transfer the reward points to sub-accounts. It will 
be appreciated that in other embodiments, reward points could accrue to individual 
sub-accounts, if the buyer so desires. Reward or reward points can later be used, for 
example, to make a payment for a purchase, to receive seller discounts, to purchase 
frequent flyer miles, etc. It will be appreciated by those of ordinary skill in the art 
that reward points can be earned by the buyer and applied to his or her virtual 
payment account in a myriad of different ways. 

It will also be appreciated that a similar process is performed for a seller to 
become an authorized or registered seller. In one embodiment, a seller can apply to 
become a participant by completing an application form on-line. In another 
embodiment, a seller applies to become a participant of the. system using a more 
traditional manual application procedure. In yet another embodiment, some 
combination of an on-line and manual process is used. It will be appreciated that if 
the seller application process is performed in whole or in part on-line, a Web browser 
component (not shown in FIGURE 4) is used to display Web pages on the seller's 



1 

* * 



WO 00/79452 PCTAJS00/16669 

-19- 



computer display 72. The seller forms a contract with the provider of the commerce 
gateway 52. In one exemplary embodiment, this contract includes terms such as the 
billing period and the fee that will be paid to the commerce gateway provider. Since 
a seller is selling a product to a buyer who has a virtual payment account, the seller 
5 will not have sub-accounts in the same sense that a buyer has sub-accounts. 
However, a seller selling different types of data can have different accounts. For 
example, a book store may have a general account and one or more restricted 
accounts, for example, the restricted accounts may prohibit sales of adult products to 
minors. This can be in the form of a rating system (e.g., G, PG, PG13 NCI 7 R 

1 0 etc.). In a similar manner to the buyer application process, once a seller has been 
approved and the seller account customized, a digital certificate is installed on the 
seller's computer 51 to identify the seller as a registered seller in the virtual payment 
system. The digital certificate is used in combination with a secret key generated by 
the seller server 51 and a public key generated by the seller server and sent to the 

1 5 gateway 52 to encrypt/decrypt messages for greater security. 

It will be appreciated, as described earlier, that a seller can apply for a "buyer- 
account. In other words, a seller can purchase products as the owner of a virtual 
payment account. 

Digital Security 

20 The illustrated embodiment also allows a buyer to create a custom package of 

sub-accounts. As will be readily recognized by those of ordinary skill in the art, the 
buyer may be provided with any number, type or combination of sub-accounts 
depending on the desires of those providing and administrating the virtual payment 
system of the present invention. 

25 The buyer can add sub-accounts (e.g., supplemental users, young shoppers, 

etc.) via the Web pages 650 shown in FIGURE 9C. Sub-accounts can be customized 
for young shoppers as shown in FIGURE 9C, for example, by setting spending limits 
for the young shopper and identifying only those seller Web sites from which the 
young shopper can purchase products. 

30 As will be described in more detail below, once the virtual payment account 

has been authorized 114 and customized, a digital certificate is transferred by the 
commerce gateway 52 and installed 128 on the buyer computer 50. The digital 
certificate is then used in subsequent transactions as a unique credential to identify 
the buyer as a registered holder of a virtual payment account. In an actual 

35 embodiment of the present invention, a buyer or seller is identified as a registered 
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user of the virtual payment system by the commerce gateway 52 verifying the 
commerce gateway's digital signature on the digital certificate associated with the 
buyer's virtual payment account 

It will be appreciated that several levels of security can be imposed on on-line 
transactions. Moving from the lowest level to the highest level, there can be: (1) no 
security restrictions imposed; (2) minimal security, such as account name and 
password verification; (3) intermediate security, such as a digital certificate or secret 
key; (4) high security, such as a transaction signed with a digital signature using the 
buyer's secret key; or (5) maximum security, such as a digital signature and additional 
access controls, such as an account number, a last purchase verification, smart cards, 
secure tokens or some combination thereof. As will be described later, in the actual 
embodiment of the virtual payment system described herein, the term "digital 
certificate" is used to describe the authorization used; however, it will be appreciated 
that a higher level of security such as a digital signature, or a digital signature with 
additional access controls may be desired in order to ensure the highest level of 
security for all parties involved (i.e., the buyer, the seller, the commerce gateway, and 
the credit processing server) in virtual payment account transactions. 

In one exemplary embodiment of the security transaction, the seller server 51 
digitally signs a purchase offer with a certificate issued by the commerce gateway 52 
and sends it to the buyer computer 50; the buyer computer 50 digitally signs the 
purchase offer with a certificate issued by the commerce gateway 52 and sends it 
back to the seller server 51; the seller server 51 then forwards the doubly signed 
purchase offer to the commerce gateway 52; the commerce gateway 52 verifies both 
signatures and if they are both valid and the transaction is permissible then signs the 
doubly signed offer and returns the resulting triply signed purchase offer to the seller 
server 51; the seller server verifies the commerce gateway's 52 signature, and if it is 
valid, then the purchase transaction is complete. In the aforementioned example, the 
seller server 5 1 may notify the buyer computer 50 or they may not. 

Ordering Products 

Once a buyer has created and customized his or her virtual payment account, 
he or she can immediately order products via the Internet if he or she was granted 
credit during the account application process. If, however, the buyer's virtual 
payment account is only a prepaid account, prepayment must be made before the 
buyer can order products. In an alternate embodiment, the buyer with only a prepaid 
account can order products, however, shipment of the product will be held until the 
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prepaid account is sufficiently funded to cover the purchase. More specifically, this 
would allow any registered buyer to have a form of "digital layaway" and by ordering 
products directly from the Web site of any registered seller. It will be appreciated 
that in yet another embodiment, buyer and seller will use the same type of virtual 
payment accounts and that any buyer can therefore act as a seller and vice versa 
Additionally, it will be appreciated that a seller can be an auction Web site, in which 
a buyer uses his. or her virtual payment account to pay for the goods, services and/or 
content purchased from the auction Web site. 

In one actual embodiment of the present invention depicted in 
FIGURES 1 1 A-l 1C, the buyer may "surf the Web" and visit a registered seller's Web 
site, such as "Virtual Store," 1 100 using the Web browser 64. Once the buyer visits a 
registered seller's Web site, the buyer may order and pay for products offered from 
that Web site using his or her virtual payment account. More specifically, a buyer 
using buyer computer 50 and Web browser 64 may retrieve the Web page 1 1 00 
shown in FIGURE 1IA from the seller Web site fictitiously known as "Virtual 
Store." The buyer makes a selection of a particular product 1 105 by manipulating a 
graphics cursor with a pointing device, such as a mouse above the selection 1110 and 
"single-clicking." It will be appreciated that other pages, for example, a query page 
in which the buyer requests products by a keyword, may be displayed. It will also be 
appreciated that the Web page 1 100 shown in FIGURE 1 1A is a simplified example. 
It is common for a seller site to allow a buyer to select multiple products and place 
them in a "shopping cart." The buyer can then view the items in the cart and, if 
desired, remove items from the cart. Once the buyer has selected the desired items 
for purchase, the buyer indicates a desire to purchase the selected items, for example, 
by clicking an "OK" or a "Buy" button. In the simplified example shown in 
FIGURE 11 A, the buyer selects an item, such as the Virtual Store Personal 
Computer 1105 and presses the "Order" button 1110 to initiate the purchase 
transaction. 

After initiating the purchase transaction, the seller server 5 1 provides the Web 
browser 64 of the buyer's computer 50 with the Web page 1 1 50 shown in 
FIGURE 11B which requests shipping information 1160, such as a street address, 
from the buyer. Additionally the Web Page 1 150 includes various payment options, 
i.e., major credit cards, such as VISA® or MASTERCARD®, with electronic 
transmission of credit information. In accordance with the present invention, a 
virtual payment account option is also displayed as a payment option for registered 
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sellers. After entering the shipping and payment information 1 160 and selecting the 
virtual payment option 1 155, the buyer can continue by clicking on the "Purchase" 
option 1165. In an actual embodiment of the present invention the buyer 
authenticator 65 displays a window 1 170 requesting the buyer to select their choice of 
5 accounts 1 172, along with an authenticating pass phrase 1 175. After selecting an 
account and entering the correct pass phrase, the buyer clicks "Continue" 1 1 77 to 
proceed with the purchase. In response, the seller server 51 calculates the total cost 
of the order, including tax and shipping and handling, and the buyer is presented with 
a confirmation screen 1180 as shown in FIGURE 11 C. After authorizing the 
10 purchase, the buyer may be presented with a payment confirmation screen 1 1 85 as 
shown in FIGURE 11 D. Additionally, the buyer may be presented with an order 
confirmation screen 1 190 as shown in FIGURE 1 IE. 

FIGURE 12 illustrates the logic implemented by the Web browser 64 
installed on the buyer computer 50 when the virtual payment account option 1 155 is 
1 5 selected. The logic begins in a block 220 and proceeds to a block 222 where a secure 
connection between the buyer computer 50 and commerce gateway 52 is established. 
In an actual embodiment of the present invention, the Secure Socket Layer (SSL) 
protocol is used for establishing a secure connection. SSL uses public key encryption 
incorporated into a Web browser, such as NETSCAPE NAVIGATOR® Web 
20 browser and Netscape's commerce servers, to secure the information being 
transferred over the Internet. The logic then proceeds to a block 224 where a buyer 
authenticator component 65 on the buyer computer 50 is executed. It will be 
appreciated that the buyer authenticator component 65 can also be included, in part or 
in whole, in the Web browser 64. The buyer authenticator component 65 is shown in 
25 more detail in FIGURE 13 and described next. 

The buyer authenticator 65 determines whether a buyer is a registered holder 
of a virtual payment account or put another way, a registered participant in the closed 
virtual payment system of the present invention. The logic of FIGURE 1 3 begins in a 
block 243 and proceeds to a block 244 where an authentication request and container 
30 are received from the Web browser 64. The container includes: transaction 
information, such as purchase detail; identification of the parties, such as a buyer 
identification which identifies the buyer, e.g., the digital certificate previously issued 
to the buyer when he or she created the virtual payment account as described above; 
and a seller identification, e.g., the digital certificate issued to the seller upon creation 
35 of a seller account; and context, such as transaction date and time. It will be 
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appreciated that the container is initially empty, and data is then added to the 
contamer by various components. As stated earlier, embodiments of the invention 
.mplement the buyer authenticator 65 in the Web browser 64. In one actual 
embodnnen,, the buyer authenticator 65 is an apple, operating from within the Web 
browser 64. 

Next, in decis,on block 246, a test is made to determine if a digital certificate 
.s mstalled on the buyer computer 50. The digital certificate may be stored in the 
buyer computer 50 memory 63 or one some other device associated with the buyer 
computer such as a secure token, a smart card or encrypted on some computer 
readable medmm. ], will be appreciated that other methods of digital identification 
can be used. If the digital certificate is installed, the digital certificate identification 
b mserted into the authentication container and the authentication request and 
contamer are returned to the Web browser in blocks 248 and 250. The container can 
be any one of a variety of data formats, for example, one embodiment of the present 
mventmn a proprietary protocol is used. In an actual embodiment of a present 
mvennon, a public key generated by the buyer's computer and signed by the 
commerce gateway (thereby forming a digital certificate) is also inserted into the 
eontamer. The secret key is never transmitted anywhere in the virtual payment 
system of the present invention. The combination of the secret key and the digital 
certificate provides a heightened level of security to the buyer authentication process 
A digital SI gnature is generally a document that has been encrypted by the secret key 
of a pubhc key pair. Only the public key of the same key pair will be able to decrypt 
•he document to its original form. This is particularly useful in demonstrating that 
only the holder of the secret key is able to sign (encrypt) the document. In practical 
terms, s.gmng a large document using public key cryptography can be very time 
consuming. Almost equally effective is creating a cryptographic message digest of 
the document and then encrypting the digest with the secret key. Therefore those of 
ordmary skill in the art will appreciate that anyone knowing the corresponding public 
key and the digest algorithm will be able to verify that the message was not altered 
and that it originated from the holder of the corresponding secret key. I, will be 
appreciated that the digital certificate as used herein refers to an authentication 
.dent,fier that is recognized by the provider of the virtual payment account that 
adheres to the provider's non-repudiation purchase policies. 

If however, in decision block 246 it is determined that a digital certificate is 
not mstalled on the buyer computer 50, the logic proceeds to a decision block 252 
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where a test is made to determine if "certificate not present" processing should be 
performed. Certificate not present processing allows a buyer to manually enter 
. . identification information when a digital certificate is not present. The identification 
information can include information such as an e-mail address, a password and 
5 personal information, for example, a mortgage payment amount. If the result of 
decision block 252 is positive, the logic proceeds to an alternate authentication in 
block 254. The alternate authentication is shown in more detail in FIGURE 14 and 
described next. 

The logic of FIGURE 14 begins at a block 1401 and proceeds to block 1405 
10 where the authorization options are displayed to the buyer. Next, it is determined in a 
block 1410 if the buyer requested an authorization code as the alternate authorization 
mechanism. If the buyer did choose to receive an authorization code, then the Web 
browser 64 on the buyer computer is sent an authorization code entry form in a block 
1415 and the authorization code is sent to an authentication device in a block 1420. 
15 Exemplary authentication devices 2800 or 2900 are shown in FIGURES 28 and 29 
respectively. After receiving the authorization code, the buyer enters the code in the 
authorization code entry form in a block 1425. 

If however at block 1405 the buyer decides not to request an authorization 
code, then from block 1410 the logic flows to a block 1450 where an interactive 
20 authentication Web form 3000 is sent to the Web browser 64 on the buyer's 
computer 50. An exemplary interactive authentication Web form 3000 is shown in 
FIGURE 30. Next in a block 1455 the buyer completes the interactive authentication 
Web form 3000. 

Next, the completed authorization entry form from block 1425 or 1455 is 
25 transmitted to the commerce gateway 52 in a block 1430. The logic then proceeds to 
a block 1 435 where it is determined whether the authentication was successful. If the 
authentication was successful the logic ends at a block 1498 returning a successful 
authentication. If the authentication was unsuccessful the logic ends at a block 1 499 
returning an unsuccessful authentication. 
30 Returning to FIGURE 13 the logic then moves to a block 256 where the 

information from the alternate authentication process is passed back through the 
buyer authenticator 65 and the logic ends at block 262. If there is no digital 
certificate installed ("No" in decision block 246) and certificate not present 
processing is not going to be performed, for example by a user selecting 
35 "cancer 3010 in the certificate not present authorization Web page 3000 shown in 
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FIGURE 30 (or "No" in decision block 252), the buyer likely does not have a virtual 
payment account. Accordingly, the logic of FIGURE 1 3 proceeds to a decision 
block 258 where a test is made to determine if the buyer wishes to apply for a virtual 
payment account. If the buyer wishes to apply for a virtual payment account, the 
5 logic proceeds to a block 260, in which the buyer is allowed to apply for a virtual 
payment account as shown in FIGURE 15 and described next. Otherwise, the buyer 
authenticator 65 returns an unsuccessful authorization message to the Web 
browser 64 in a block 261 and the logic ends in block 262. 

FIGURE 15 illustrates the logic implemented by the Web browser 64 when a 
10 buyer applies for a virtual payment account. It will be appreciated that applying for a 
virtual payment account can be invoked by a buyer requesting an account directly 
from the commerce gateway 52 or by a buyer who is not registered attempting to 
order a product from a registered seller. In either case, the logic for applying for a 
virtual payment account via a Web browser 64 begins in a block 270 and proceeds to 
15 a block 272 where a request for an application form is received by the Web 
browser 64. Next in a block 273, the request for an application form is sent to the 
Web server component 87 of the commerce gateway 52, The requested application 
form is then received from the Web server component 87 of the commerce 
gateway 52 and displayed in the buyer's Web browser in a block 274. 
20 Next, in a block 275, the completed account application form is sent to the 

commerce gateway 52 and processed by an enrollment server component 89 as 
shown in FIGURE 1 6, and described next. In another embodiment, the account 
application is sent to the transaction server component 84 that handles financial 
transactions and also handles non-financial transactions, such as enrollment. 
25 The logic of the enrollment server 89 shown in FIGURED 6 begins in a 

block 280 and proceeds to a block 282 where a completed application form is 
received from the Web browser. Next, in a block 283 identity information, such as 
name, employer, current residence, etc., is requested from an identity bureau 56 via 
the identity bureau adapter 79 whose logic is shown in FIGURE 27 and described 
30 next. 

» 

Accordingly, the logic of FIGURE 27 begins in a block 2705 and proceeds to 
a block 2710 where the identity request is received. The request is then formatted to 
be compatible with the particular identity bureau in a block 27 1 5. Next, the logic 
proceeds to a block 2720 where the formatted request is then sent to identity 
35 bureau 56. The result of the request is received from the identity bureau in a 
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block 2725. Next, in a block 2730, the result is then returned to requester. The logic 
of FIGURE 27 then ends in a block 2735. 

Returning to FIGURE 16, if in a block 284, which in this case is the 
enrollment server 89, it is determined that the identity information received from the 
5 "Identity bureau 56 via the identity bureau adapter 79 corresponds to the information 
in the application received in block 282, then processing continues to a block 285 
where the enrollment server requests credit information, such as income, length of 
time with current employer, length of time at current residence, etc., from a credit 
bureau 58 via the credit processing server adapter 86 as shown in FIGURE 21 and 
1 0 described later with reference to a purchase authorization request. 

Upon receipt of the credit information, the logic proceeds to a block 286 
where the application is scored based on the identity bureau information and credit 
bureau information in combination with internal criteria. The internal criteria 
provide a score for the various pieces of credit information. For example, incomes 
15 will be broken down into ranges, with a point value assigned to each range. 
Similarly, point values will be assigned based on the time the applicant has lived at 
his or her current residence, etc. The points for each piece of credit information are 
combined to determine a score for the applicant. The score equates to the credit 
worthiness of the buyer and is used to determine if the applicant will receive a credit 
20 account, or if the score falls in an intermediate range, a prepaid account, and if so, to 
establish a credit limit for the applicant, i.e., buyer. Next, if the score is above a 
threshold logic ends with a successful enrollment result returned to the Web browser 
in a block 288. However if the score is below a certain threshold or if the identity 
information provided by the identity bureaus 56 does not correspond to that of the 
25 buyer's application, then an unsuccessftil result is returned in a block 289. Processing 
then returns to FIGURE 1 5. 

In FIGURE 15, once a response is received from the enrollment server 89 a 
block 265 examines whether an account was created. If it was then a request is sent 
to the buyer computer 50 to generate a public key encryption pair in block 267 and to 
30 submit the public key to the enrollment server 89 on the commerce gateway 52. The 
enrollment server then signs the public key to create a digital certificate and returns a 
successful enrollment Web page 620, as shown in FIGURE 8E which is received in a 
block 276 along with the digital certificate in a block 278. If at block 265 it was 
determined that an account was not created then an unsuccessful application Web 
35 page is displayed (not shown) at a block 266. In the case of applying for a virtual 
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payment account, the result page 620 provides details of the new account for the 
buyer, or contains a message informing the buyer that there was an error creating the 
- Recount. The logic of FIGURE 15 of applying for a virtual payment account then 
ends in a block 279 and processing returns to FIGURE 13. 

5 Referring again to FIGURE 13, after the buyer has applied for a virtual 

payment account, the logic returns to decision block 246 where the test to determine 
if a digital certificate is installed on the buyer computer 50 is repeated. Depending on 
the results of decision block 246, either blocks 248-250 or blocks 252-256 are 
repeated for the recent applicant of a virtual payment account. The logic then ends in 

10 a block 262. 

While the logic of authenticating a buyer as shown in FIGURE 13 and 
described herein uses a digital certificate as the primary means for authenticating a 
buyer, it will be appreciated that other methods are possible. Foi example, a lesser 
level of security could be employed, whereby a user could be required to enter 
15 identifying information, such as the information entered in alternate authentication 
shown in FIGURE 14. Alternatively, a greater degree of security could be employed 
whereby a digital certificate is required, and "certificate not present" processing is not 
allowed. Or, an even greater level of security could be used requiring a digital 
signature and other verifying information from the buyer. 
20 Returning to FIGURE 12, after buyer authentication is completed in 

block 224, the logic proceeds to a decision block 226, where a test is made to 
determine if the buyer authentication was successful. If not, the logic proceeds to a 
block 227 where an error message is displayed on the buyer computer 50 by the Web 
browser 64 notifying the buyer of the failed authentication. The logic of FIGURE 12 
25 ends in a block 242. 

However, if the buyer was successfully authenticated, the logic proceeds to a 
block 228 where a virtual payment account selection Web page 1170 as shown in 
FIGURE 11 B is displayed. Included in the requested information of the virtual 
payment account selection Web page 1170 is an identification of the applicable 
30 account or sub-account to which the purchase should be applied. Next, in a 
block 230, sub-account and password information (used to unlock the buyer's digital 
certificate) are obtained from the buyer from the information entered in the virtual 
payment account selection Web page 1 170 of FIGURE 1 IB when the buyer indicates 
that the information has been entered by selecting "Continue" 1177. The logic of 
35 FIGURE 12 then proceeds to a block 232 where the sub-account, and an 
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authentication container are sent to the commerce gateway 52 and processed by the 
account identification container generator 88 shown in FIGURE 1 7 and described 

- 

next. 

The logic of FIGURE 17 begins in a block 800 and proceeds to a block 802 
5 where the sub-account and authentication container are received from Web 
browser 64 of the buyer computer 50. The logic then proceeds to a block 804 where 
an internal account identification associated with authentication container is 
determined. An empty account identification container is then created in a block 806. 
Next, in a block 808, internal account identification and sub-account information is 
10 added to the empty account identification container. The logic then proceeds to a 
block 810 where an internal digital signature is applied to the account identification 
container. For example, message digest logic can be used by applying an algorithm 
that takes a variable length message and produces a fixed length digest as output 
using a one-way hashing algorithm that establishes the message as cryptographicaJly 
15 secure. Finally, the account identification container is returned to the Web 
browser 64 in a block 812. The logic of FIGURE 17 then ends at a block 814, and 
processing returns to FIGURE 12. 

Returning to FIGURE 12, after the sub-account and authentication container 
are sent to the commerce gateway 52, the logic then proceeds to a block 234 where 
20 the logic waits to receive the account identification container from the account 
identification container generator component 88 of the commerce gateway 52. Once 
the account identification container is received from the commerce gateway 52, the 
logic proceeds to a block 238 where a purchase request is sent to the commerce 
engine 75 in the form of a request and account identification container for processing 
25 as shown in FIGURE 1 8 and described next. 

The commerce engine 75 is the component of the seller server 51 that 
determines whether or not the order will be processed and whether the requested 
product will ultimately be provided to the buyer. It will be appreciated that 
commerce engines are well known in the art. The commerce engine component 75 
30 used in conjunction with the commerce gateway adapter component 76 allows the 
virtual payment system of the present invention to expand existing technology that is 
currently used for traditional credit systems to encompass the virtual payment 
account of the present system. It will be further appreciated that while the 
embodiment shown and described modifies the commerce engine to achieve this 
35 functionality (which may be possible through existing API calls of the commerce 
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engine), other embodiments are possible. This expanded commerce engine 
funclionality is shown in FIGURE 18. 

The logic of FIGURE 1 8 begins in a block 300 and proceeds to a block-302 
where a purchase request and account identification container are received from the 
5 Web browser 64 of the buyer computer 50. The logic then proceeds to a decision 
block 304 where a test is made to determine whether the purchase request should be 
forwarded to the commerce gateway adapter 76. If the purchase request is to 
purchase products using a virtual payment account, the request should be forwarded 
to the commerce gateway adapter 76 for processing in accordance with the virtual 
1 0 payment system of the present invention. In another embodiment, only the request 
(without the account identification container) is received from the Web browser in 
block 302, and if it is determined in decision block 304 that the purchase request 
should be forwarded to the commerce gateway adapter 76, the account identification 
is then obtained from the Web browser 64. In either case, if it is determined in 
15 decision block 304, that the purchase request should be forwarded to the commerce 
gateway adapter 76, the logic proceeds to a block 306 where the request is forwarded 
to the commerce gateway adapter. The commerce gateway adapter 76 is shown in 
more detail in FIGURE 19 and described next. 

The commerce gateway adapter 76 is a component residing on the seller 
20 server 51 that allows the seller server to communicate directly with the transaction 
server component 84 of the commerce gateway 52 in order to expand the 
authorization function of the commerce engine 75 to include virtual payment account 
transactions. Accordingly, the logic of FIGURE 1 9 begins in a block 330 proceeds to 
a block 332 where the forwarded purchase request and account identification 
25 container are received from the commerce engine 75. Next, in a block 334 the 
purchase request and account identification container are sent to the transaction 
server 84 in the form of a transaction request for further processing as shown in 
FIGURE 20 and described next. 

The transaction server component 84 of the commerce gateway 52 is 
30 responsible for interfacing with the other components of the system and determining 
whether or not a requested transaction should be applied to a buyer's virtual payment 
account. The logic of FIGURE 20 begins in a block 350 and proceeds to a block 352 
where the transaction request is received. Next, in a block 353 the account 
identification container is decoded and verified. The origin or source of the request 
35 as well as the context, i.e., date and time, of the request are then recorded in 
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memory 83 of the commerce gateway 52 in a block 354. Next, the logic proceeds to 
a decision block 356 where a test is made to determine whether the requested 
transaction is permissible. A variety of factors can be considered in making the 
determination of whether a requested transaction is permissible. For example, 
5 spending limits cannot be exceeded, and user-imposed limitations, such as those put 
on a young shopper account, e.g., sites from which the young shopper can make 
purchases and hours during which the young shopper can make purchases as shown 
in FIGURE 9C, cannot be violated. 

If the transaction is not permissible, the logic proceeds to a block 357 where 
]0 an impermissible transaction message is sent to the requester (e.g., the commerce 
gateway adapter 76 in the context of a purchase request). The logic of FIGURE 20 
then ends in a block 376. If, however, the transaction is permissible, the logic 
proceeds from decision block 356 to a block 360 where the transaction request is sent 
to a credit processing server adapter 86 for further processing as shown in 
1 5 FIGURE 2 1 and described next. 

The credit processing server adapter 86 is the component residing on the 
commerce gateway 52 that allows commerce gateway 52 components, such as the 
transaction server 84 and the enrollment server 89 to communicate directly with the 
various sub- systems of the credit processing server 53, which provide for the 
20 application of the requested transaction to the buyer's actual payment account. 
Accordingly, the logic of FIGURE 21 begins in a block 380 and proceeds to a 
block 382 where the request is received. For example, a purchase authorization 
request or a refund request is received from the transaction server 84 and a credit 
information request is received from the enrollment server 89. The request is then 
25 formatted to be compatible with the appropriate credit processing sub-system, i.e., the 
account/billing sub-system 94, the payment processing sub-system 95 and/or the 
account enrollment sub-system 96, on the credit processing server 53 in a block 384. 
Next, the logic proceeds to a block 386 where the formatted request is then sent to 
credit processing server 53 for processing by the appropriate credit processing 
30 sub-system, as shown in FIGURE 22 and described next. 

For any credit processing sub-system, the logic of FIGURE 22 begins in a 
block 390 and proceeds to a block 392 where the transaction request is received from 
the credit processing server adapter 86. Next, account data and sub-account data are 
retrieved in block 394 from the appropriate database, e.g., account database 97 and 
35 financial database 98. Standard credit transaction processing is then performed in a 
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block 398. Examples of standard transactions for the account/billing sub- system 94 
include: creating and maintaining accounts, including holding account information 
and account holder information, such as name and address; calculating interest; 
calculating minimum monthly payments; generating electronic monthly statements; 
5 and calculating other charges, known as discounts. The discount is the portion of the 
transaction amount that will go to the provider of the commerce gateway 52, and can 
be determined on a fixed amount per transaction basis, or a percentage of transaction 

■ 

amount basis. Examples of standard transactions for the payment processing sub- 
system 95 include: collecting payments from buyers and applying the payments to the 

10 buyers account; transferring funds between sellers and buyer, for example by 
interfacing with financial institutions 59 for ACH transactions. Examples of standard 
transactions for the account enrollment sub-system include: obtaining credit 
information from credit bureaus; providing the credit information to the commerce 
gateway 52 for scoring; determining a credit score based on the credit information 

15 and providing the score to the commerce gateway; and providing scoring information 
to the account/billing sub-system 94 for account creation. 

The logic then proceeds to a block 399 where necessary account adjustments 
are applied, if applicable. For example, the account balance will be reduced by the 
amount of an authorized purchase transaction. In one embodiment of the present 

20 invention, reward points are accrued at the time of purchase, but committed later, for 
example during the periodic, e.g., monthly, statement preparation process. 
Alternatively, reward points may not accrue until payment is made for the product to 
which the points are attributed. Next, the transaction result, such as the credit 
information or the purchase authorization, is sent to the credit processing server 

25 adapter 86 in a block 400. The logic of FIGURE 22 then ends in a block 402 and 
processing returns to FIGURE 21. 

Returning to FIGURE 21, the result of the transaction request is received 
from the credit processing sub-system 94, 95 or 96 in a block 387. Next, in a 
block 388, the result is then returned to requester, e.g., the result of a purchase 

30 authorization request is returned to the transaction server 84 and credit information, 
for example, a credit limit, is returned to the enrollment server 89 in response to 
request for a credit information request to be used for establishing a buyers account. 
The logic of FIGURE 21 then ends in a block 389 and processing returns to the 
requester, e.g., transaction server 84 (FIGURE 20) or enrollment server 89 
35 (FIGURE 1 6). 
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Returning to FIGURE 20, once the transaction server receives the response to 
its transaction request, e.g., authorization result of a purchase request, from the credit 
processing adapter in a block 363, the logic proceeds to a block 364 where the 
transaction record, for example purchase information including amount of purchase, 
5 is stored in memory 83 of the commerce gateway 52. The logic then proceeds to a 
decision block 366, where a test is made to determine if the transaction was 
successfully processed. If so, the logic proceeds to a block 370 where a transaction 
response with a valid status is then sent to the requester (e.g., the commerce gateway 
adapter 76 or the Web browser 64, whichever the case may be). If the transaction 
10 was not successfully processed, the logic proceeds from decision block 366 to a 
block 374 where a transaction response with an error status is then returned to the 

requester in a block 376. 

After a valid transaction response 370, an error transaction response 374, or 
an impermissible transaction response 357 is sent to the requester, the logic of 
15 FIGURE 20 ends in block 376 and processing returns to the requester. In the case of 
a purchase request, the requester is the commerce gateway adapter 76. In one 
exemplary embodiment, a record of all transactions is stored in the financial 
database 98. 

Returning to FIGURE 1 9, after the response to the purchase request made by 
20 the commerce gateway adapter 76 is received from the transaction server in a 
block 336, the logic proceeds to a block 338 where the response including the 
transaction status is formatted to be compatible with the commerce engine 75. The 
formatted response is then forwarded to the commerce engine in a block 340. The 
logic of FIGURE 19 then ends in a block 342 and processing returns to the commerce 
25 engine 75 in FIGURE 1 8. 

Returning to FIGURE 1 8, once a response is received by the commerce 
engine 75 from the commerce gateway adapter 86 in a block 308, the authorized and 
ordered product is shipped to the buyer in a block 310. It will be appreciated by those 
of ordinary skill in the art that if the ordered product is capable of being downloaded, 
30 e.g., the product is an electronically stored good, a URL for a premium content Web 
site, etc., the product will simply be transferred by the seller server 51 to the buyer 
computer 50. Otherwise, the product will be shipped or provided by more traditional 
methods, e.g., regular mail, hand delivery, etc. Once shipment is complete, the logic 
then proceeds to a block 312 where a settlement request is sent to the commerce 
35 gateway 52 in order to initiate movement of funds. In an actual embodiment of the 
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present invention, the seller submits the transaction into a settlement batch for 
payment when the settlement batch for that seller is next processed. The timing of 
the processing could be that night or at a later date based on the contract, i.e., terms 
of the purchase transaction. FIGURE 41 illustrates an exemplary Web page 41 00 for 

5 designating when batches should be processed. Settlement transactions are described 
in FIGURE 24 in more detail below with reference to FIGURE 24. 

Returning to FIGURE 1 8, in a block 3 1 4, a response confirming fulfillment of 
the order is sent to the Web browser 64 of the buyers computer 50. The logic of 
FIGURE 18 then ends in a block 324. 

10 However if at decision block 304, it is determined that the purchase request 

should not be forwarded to the commerce gateway 52; the logic proceeds to a 
block 316 where standard commerce engine processing is performed. More 
specifically, in block 316 traditional credit or debit card authorization is performed 
such as approval or denial for the use of a credit card, e.g., VISA® or 

15 MASTERCARD®, for the specified purchase amount. Next, the authorized goods 
are shipped in a block 318. The logic then proceeds to a block 320 where a 
settlement request is sent to the traditional credit provider, e.g., VISA® or 
MASTERCARD®. A response confirming fulfillment of the order is then sent to the 
Web browser 64 of the buyer computer 50 in a block 322. The logic of FIGURE 1 8 

20 then ends in block 324 and processing returns to FIGURE 12. 

Returning to FIGURE 12, once the Web browser 64 of the buyer computer 50 
receives a response to its purchase request in a block 240, the logic proceeds to a 
block 241 where an order confirmation Web page 1190 is displayed as shown in 
FIGURE 1 1 E. The logic of FIGURE 1 2 then ends in block 242. 

25 FIGURE 23 is a diagram illustrating the actions taken by the buyer's 

computer 50, the seller server 5 1 and the commerce gateway 52 for ordering products 
using a virtual payment account system. This diagram presents a high-level view of 
the detailed processing shown in the flow charts described above. In response to an 
inquiry into purchasing a product 2305, a seller returns a purchase offer 2310 to the 

30 buyer's computer 50. At this point, the buyer has the option of beginning the 
purchasing process as shown in FIGURE 12. To continue the buyer authenticator 65 
checks to see which credentials, e.g. certificates, are available to the buyer and selects 
all available credentials to be used by the commerce gateway 23 1 5 to authenticate the 
buyer. The buyer computer 50 then requests a list of all accounts or sub-accounts 

35 2320 for these credentials from the commerce gateway 52. The commerce gateway 
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52 returns only those accounts that are usable by the buyer 2325 using the selected 
credentials. The buyer computer 50 then generates a purchase confirmation 2330 
using one of the accounts on the list returned from the commerce gateway 52. Buyer 
computer 50 then sends the purchase confirmation 2335 to the seller server 51. The 
seller server 51 requests authorization 2340 from the commerce gateway to verify 
that the purchase confirmation is valid. The commerce gateway then returns an 
authorization 2350 that the purchase confirmation is valid. The seller server 51 may 
then notify 2355 the buyer computer 50 that the purchase confirmation was 
authorized. The seller server then prepares the purchase for delivery 2360. At this 
point, the seller may request a settlement transaction 2365 from the commerce 
gateway 52. Which would then provide a settlement transaction 2370 back to the 

r 

seller server 51. The seller server 51 may then notify 2375 the buyer computer 50 of 
delivery details. Finally, the good(s) or service(s) that the buyer purchased are 
delivered 2380. 

If the seller is an auction Web site, the authorization 2340 sent by the 
commerce gateway 52 to the seller server 51 includes information such as a buyer 
account identification, a seller identification, a seller sale offering, a buyer 
authentication, a seller authentication, and a master identification, i.e., identification 
of the commerce gateway 52 provider. Particular to this type of response is an 
expiration date/time that is used to signal the shorter of the maximum times that the 
buyer and the seller are willing to "reserve" funds associated with this transaction. If 
the transaction, i.e., settlement request 2365, is not received by the commerce 
gateway 52 before the expiration date/time of the transaction, the products and/or 
funds will be released back to their owners. At a later time, once the buyer has 
committed to the purchase, the buyer releases an authorization to the provider of the 
commerce gateway 52 knowing that the seller has proven ability to ship the products 
on demand without delay. This initiates the actual settlement of funds and triggers 
payment to the seller in the next settlement batch, without any further interaction with 
the seller. This payment method supports buyer-initiated, pre-approved purchases 
with expiration date/time, such as auction and gift-certificate purchases. 

It will be appreciated that FIGURE 23 illustrates processing of a valid 
purchase transaction. If there is an error at any time during the processing, e.g., buyer 
is not authorized because he or she is not a registered buyer, has exceeded his or her 
spending limit, etc., processing will terminate after an appropriate error response has 
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been returned to the buyer computer 50 for display to the buyer via the Web 
browser64. 

Settlement Transaction 

account, a contract is formed defining the 

5 relationship between the seller and the commerce gateway provider. That contract 
defines the terms, such as when payments will be funded and what fee shall be given 
to the commerce gateway provider. The commerce gateway fee can be a per 
transaction fee or a percentage fee based on the amount of a transaction. The logic 
for settlement transactions for a virtual payment account is similar to the logic used 

10 for processing standard credit card settlement transactions. After the seller ships the 
product, the seller sends a settlement transaction to the commerce gateway 52 as 
shown in FIGURE 24. It will be appreciated that the logic performed by the seller 
server 51 can be performed by the commerce engine component 75, or some other 
component, for example, a Web browser (not shown) residing on the seller server 51 

15 FIGURE 24 illustrates the logic implemented by seller server 51 when the 

seller wishes to perform a settlement transaction. The logic begins in a block 530 and 
proceeds to a block 532 where a secure connection between the seller computer 5 1 
and commerce gateway 52 is established, using the same logic shown and described 
with reference to the buyer in block 222 of FIGURE 12. The logic then proceeds to a 

20 block 534 where the seller authenticator process is run. The seller authenticator 
process is similar to the buyer authenticator process shown in FIGURE 1 3 and 
described above. Next, in a decision block 536 a test is made to determine if the 
seller is a registered participant (i.e., seller's digital certificate was issued by the 
commerce gateway provider, seller's digital certificate has not expired and seller's 

25 digital certificate has not been revoked). If not, the logic proceeds to a block 538 
where a seller authentication error message is displayed on the seller server 
display 72, for example, via a Web browser. The logic of FIGURE 24 then ends in a 
block 548. 

If the seller authenticator process is successful, the logic proceeds from 
30 decision block 536 to a block 544 where a settlement request is sent to the transaction 
server 84 on the commerce gateway 52. As shown and described in FIGURE 25, the 
transaction server 84 forwards the request to the credit processing server adapter 86, 
which in turn forwards the transaction request to the appropriate credit processing 
sub-system. In the case of a settlement transaction request, the payment processing 
35 sub system 95 processes the transaction. The payment processing sub-system 
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forwards the settlement request to the financial institution 59. The financial 
institution funds the transactions into the commerce gateway provider's account. The 
commerce gateway provider takes its percentage and pays the sellers their portion. 
The financial institution 59 waits for their billing cycle, e.g., monthly, and then 
5 charges the buyers for their purchases plus interest charges. The financial institution 
waits for the buyer payments. If the buyer does not pay, standard late payment 
processing, such as late notices, finance charges, etc. is performed. 

The logic of FIGURE 25 begins in a block 2505 and proceeds to a block 2510 
where the settlement request is received. The origin or source of the settlement 
10 request as well as the context, i.e., date and time, of the request are then recorded in 
memory 83 of the commerce gateway 52 in a block 2515. Next, the logic proceeds to 
a decision block 2520 where a test is made to determine whether the requested 
settlement is permissible. A variety of factors can be considered in making the 
determination of whether a requested settlement is permissible. Some factors might 
15 include a settlement request for a transaction that did not have a purchase 
confirmation from a buyer, that had a purchase confirmation from a buyer whose 
account did not hold sufficient funds, for an auction settlement whose time had 
expired or whose credentials were no longer valid. It will be appreciated that yet 
other factors may cause a settlement transaction to be impermissible. If the 
20 transaction is not permissible, the logic proceeds to a block 2560 where an 
impermissible settlement request message is sent to the requester, i.e., the seller, in 
this case. If, however, the transaction is permissible, the logic proceeds from 
decision block 2520 to a block 2525 where the transaction request is sent to a credit 
processing server adapter 86 for further processing as shown in FIGURE 21 and 
25 described above. Continuing in FIGURE 20, once the transaction server receives the 
response to its transaction request, e.g., authorization result of a settlement request, 
from the credit processing adapter in a block 2530, the logic proceeds to a block 2535 
where a transaction record, for example purchase information including amount of 
purchase, is stored in memory 83 of the commerce gateway 52. The logic then 
30 proceeds to a decision block 2540, where a test is made to determine if the 
transaction was successfully processed. If so, the logic proceeds to a block 2545 
where a transaction response with a valid status is then sent to the requester, i.e., the 
seller in this case. If the transaction was not successfully processed, the logic 
proceeds from decision block 2540 to a block 2555 where a transaction response with 
35 an error status is then returned to the requester. 
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Afier a valid transaction response 2545, an error transaction response 2555, or 
an impermissible transaction response 2560 is sent to the requester, the logic of 
FIGURE 25 ends in block 2550 and processing returns to the requester. 

Referring back to FIGURE 24, after the transaction server 84 has processed 
5 the settlement transaction and provided the results of the settlement transaction to the 
seller's computer 51, the result of the settlement transaction is displayed on the 
seller's display 73, for example, via the seller server's Web browser. The logic of 
FIGURE 24 then ends in block 548. 

Refund Transaction 

10 FIGURE 26 illustrates the logic implemented by the present invention when a 

refund transaction is initiated, for example, when a buyer disputes a charge on his or 
her virtual payment account. As with any payment dispute, it must be determined 
whether the buyer will receive all or a portion of the disputed amount. This process 
is external to the virtual payment system of the present invention. The determination 

15 of whether the dispute has merit is determined by the seller. If the seller determines 
that the dispute has merit, the seller notifies a customer service representative and a 
refund transaction is initiated. In the embodiment shown in FIGURE 26 and 
described herein, if it is determined that an amount disputed by a buyer is subject to a 
refund, a customer service representative initiates the refund, or chargeback 

20 transaction via the administrative computer 54 shown in FIGURE 2. In one actual 
embodiment, the administrative computer is a "dumb terminal" by which the 
customer service representative enters information directly into the transaction 
server 84 on the commerce gateway 52. In another embodiment, the administrative 
computer may have a Web browser that allows the administrator to enter the 

25 information using Web pages available only on the LAN 44 behind the firewall 55, 
i.e., the buyer and seller do not have access to these administrative Web pages. 

Referring to FIGURE 26, the logic begins in a block 550 and proceeds to a 
block 552 where the refund information including account, sub-account and amount 
is obtained. The refund transaction information is then sent to the transaction 

30 server 84 by the administrative computer 54 in a block 554 in the form of a refund 
request. Transaction server 84 processing is shown and described with reference to 
FIGURE 20. 

As also noted above, in processing the refund request, the transaction 
server 84 will forward a transaction request to the credit processing server 53 for 
35 processing by the account/billing sub-system 94 as shown in FIGURE 22. A refund 
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applied to a buyer's virtual payment account causes the buyer's balance to decrease 
by the amount of the payment. Still referring to FIGURE 26, after the transaction 
server 84 has processed the refund transaction, the result of the transaction processing 
is received and displayed by the administrative computer 54. The logic of 

5 FIGURE 26 then ends in a block 558. Unlike the purchase transaction, the refund 
transaction is not initiated by the buyer via the Web browser 64; therefore, the buyer 
is notified by other means, for example by sending an e-mail message to the buyers 
computer 50. It will also be appreciated that in yet other embodiments of the present 
invention, the seller server 51 may initiate the refund request as opposed to the 

1 0 administrative computer 54. 

Buyer Account Management 
Other transactions normally associated with an account such as a standard 
credit card account are also applicable to the virtual payment account of the present 
invention. FIGURES 1 OA- IOC illustrate some examples of Web pages used by a 
1 5 buyer with a virtual payment account. Processing of these transactions is similar to 
other transaction processing as illustrated in flow diagrams and described above, and 
therefore will not be discussed in further detail herein. FIGURE 10A illustrates a 
Web page 660 containing details of a primary account 632 along with sub- 
accounts 634. FIGURE 10B illustrates an exemplary Web page 665 summarizing the 
20 sub-accounts for a master account 634. FIGURE 10C illustrates a transaction 
summary Web page 670 for the sub-accounts for a given master account. 

Seller Reports 

It is often desirable for seller's to have detailed reports available to judge the 
current state of their business. Accordingly, the present invention maintains records 

25 of transactions in readily retrievable formats. It is also desirable that competitors not 
have access to the same reports on the details of a seller's business. Accordingly, the 
present invention provides for secure authenticated access to a seller's reports. 
FIGURE 42 illustrates the logic for generating seller reports. The logic starts at a 
block 4201 and proceeds to a block 4210 that establishes a secure connection 

30 between the seller computer 51 and the commerce gateway 52. The logic then 
proceeds to a block 4215 where the seller is authenticated much as the buyer 
authenticator illustrated in FIGURE 13. The flow continues to a block 4220 where a 
test is performed to see if the seller has been authenticated. If the authentication was 
successful, the logic continues to a block 4225 where the seller requests the 

35 transaction server 84 to generate a report. At a block 4230 the transaction server 
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retrieves relevant information and generates a report, which in a block 4235 is 
received by the seller computer for viewing by the seller. The logic ends in a 
block 4299. 

In one actual embodiment of the present invention, the commerce gateway 52 
requests report information from the credit processing server 53, in particular from 
the financial database 98 stored on the credit processing server. It will be appreciated 
by those of ordinary skill in the art, that a financial database may be used to store 
information forreport generation, yet may also store information relevant for other 
purposes. 

FIGURES 31, 33, 35, 37 and 39 illustrate exemplary Web pages 3100, 3300, 
3500, 3700 and 3900 illustrating exemplary reports available to a seller. FIGURE 31 
shows an exemplary Web page 3100 with a graph charting the number of sales 
occurring each month during a year-long period. FIGURE 33 shows an exemplary 
Web page 3300 with a table indicating the status and information on particular orders 
received. FIGURE 35 shows an exemplary Web page 3500 with a table listing 
transactions that have already been processed for each order, and the result of that 
processing. FIGURE 37 shows an exemplary Web page 3700 with a table listing 
item sales and along with relevant statistics such as number of units sold, what 
percentage of units have been sold and what percent of overall sales does that item 
account for. FIGURE 39 shows an exemplary Web page 3900 with a table listing 
transactions that have yet to be processed and are still wait for the next batch of 
transaction to be run. 

FIGURES 32, 34, 36, 38 and 40 illustrate exemplary Web page forms 3200, 
3400, 3600, 3800 and 4000 for customizing seller reports. 

While the preferred embodiment of the invention has been illustrated and 
described, it will be appreciated that various changes can be made therein without 
departing from the spirit and scope of the invention. For example, it will also be 
appreciated that there are other transactions applicable to a virtual payment account 
of the present invention, e g., account closure, credit limit modification, overdue 
account notification, etc. It will be appreciated that these transactions can be initiated 
by various components of the system, for example a financial institution may institute 
a change in a credit limit by sending a request to one of the sub-systems on the credit 
processing server. One of ordinary skill in the art will recognize that the requests for 
such transactions are processed by the virtual payment system of the present 
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invention in a manner similar to the processing of the purchase settlement, and refund 
transactions described in detail above. 
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The embodiments of the invention in which an exclusive property or privilege 
is claimed are defined as follows: 

1. A method for purchasing a product from a seller computer using a 
virtual payment account, comprising: 

receiving a request from a buyer computer to purchase said product from said 
seller computer using said virtual payment account; 

in response to said purchase request, determining whether said buyer 
computer is associated with said virtual payment account; 

in response to determining that said buyer computer is associated with said 
virtual payment account, applying a cost of said product to said virtual payment 
account; and 

providing said product to a buyer associated with said buyer computer. 

2. The method of Claim 1, wherein determining whether said buyer 
computer is associated with said virtual payment account comprises: transmitting an 
authentication request from said buyer computer to a commerce gateway; 
determining at said commerce gateway whether said virtual payment account is 
associated with said buyer computer; and transmitting an account identification 
container to said buyer computer in response to determining that said buyer computer 
is associated with a valid virtual payment account. 

3. The method of Claim 2, wherein determining at said commerce 
gateway whether said virtual payment account is associated with said buyer computer 
further comprises determining at said commerce gateway whether said virtual 
payment account is valid; 

4. The method of Claim 2, wherein said authentication request comprises 
a digital certificate. 

5. The method of Claim 4 further comprising retrieving said digital 
certificate from a secure token. 

6. The method of Claim 1, wherein determining whether said buyer 
computer is associated with said virtual payment account comprises: transmitting an 
alternate authentication request from said buyer computer to a commerce gateway; 
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sending an alternate authentication message from said commerce gateway to a buyer 
authentication device; retrieving said alternate authentication message; verifying said 
-ahemate authentication message with said commerce gateway; and in response to 
verifying said alternate authentication message determining that said buyer computer 
is associated with said virtual payment account. 

7. The method of Claim 1, wherein determining whether said buyer 
computer is associated with said virtual account comprises: transmitting an alternate 
authentication request from said buyer computer to a commerce gateway; initiating 
an alternate authentication dialog with said buyer computer; in response to said 
alternate authentication dialog determining that said buyer computer is associated 
with said virtual payment account. 

8. The method of Claim 1, wherein applying a cost of said product to 
said virtual payment account comprises: receiving said account identification 
container at said seller computer, transmitting said account identification container 
and said cost of said product from said seller computer to said commerce gateway; 
determining whether said virtual payment account may be charged for said cost of 
said product; and in response to determining that said virtual payment account may 
be charged for said cost of said product, transmitting a valid transaction authorization 
from said commerce gateway to said seller computer. 

9. The method of Claim], wherein said virtual payment account 
comprises a main account and at least one sub-account. 

1 0. The method of Claim 9, wherein said sub-account is operative only to 
accept charges from a predetermined list of seller computers. 

1 1 . The method of Claim 9, wherein a spending limit may be set by said 
buyer for said sub-account. 

1 2. A method for purchasing a product from a seller computer comprising: 
receiving a request from a buyer computer to purchase said product from said 

seller computer using a virtual payment account; 

in response to said purchase request determining that buyer computer will use 
an alternate payment mechanism; validating said alternate payment mechanism; and 

providing said product to a buyer associated with said buyer computer. 
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13. A method for purchasing a product from a seller computer using a 
virtual payment account associated with a buyer computer, the method comprising: 

receiving a request from said buyer computer to purchase said product, said 
purchase request identifying said virtual payment account as a payment source for 
said product; 

in response to said purchase request, transmitting an authentication request 
from said buyer computer to a commerce gateway; 

determining at said commerce gateway whether said virtual payment account 
is associated with said buyer computer; 

transmitting an account identification container to said buyer computer in 
response to determining that said buyer computer is associated with a valid virtual 
payment account; 

transmitting said purchase request including said account identification 
container from said buyer computer to said seller computer; 

transmitting said purchase request from said seller computer to said 
commerce gateway; 

receiving said purchase request at said commerce gateway and determining 
whether said virtual payment account may be used to pay for said product; 

in response to determining that said virtual payment account may be used to 
pay for said product, transmitting a valid transaction authorization from said 
commerce gateway to said seller computer and said buyer computer; 

charging said virtual payment account for a cost associated with said product; 

and 

providing said product to a buyer associated with said buyer computer. 

14. The method of Claim 13, wherein said virtual payment account 
comprises a main account and at least one sub-account. 

15. The method of Claim 14, wherein charging said virtual payment 
account for a cost associated with said product comprises charging said sub-account 
for a cost associated with said product. 

16. The method of Claim 15, fiirther comprising: determining whether 
said sub-account is authorized to receive a charge from said seller computer; and 
charging said sub-account for a cost associated with said product in response to 



WO 00/79452 



-44- 



PCT AJS00/1 6669 



determining that said sub-account is authorized to receive said charge from said seller 
computer. 

17. The method of Claim 13, wherein said virtual payment account 
comprises a credit account. 

18. The method of Claim 13, wherein said virtual payment account 
comprises a pre-paid account. 

19. The method of Claim 13, wherein said authentication request 
comprises a digital certificate, and wherein said digital certificate is transmitted to 
said commerce gateway. 

20. The method of Claim 13, wherein determining whether said virtual 
payment account may be used to pay for said product comprises determining whether 
a spending limit has been exceeded. 

21. A method for creating a virtual payment account for a buyer which 
may be used to pay for products ordered over an internetwork^ the method 
comprising: 

receiving application data from said buyer; 

determining a credit score for said buyer based upon said application data; 

determining whether said credit score exceeds a threshold credit score; 

in response to determining that said credit score exceeds said threshold credit 
score, establishing a virtual payment account associated with said buyer at a 
commerce gateway; and 

installing a digital certificate on a buyer computer associated with said buyer 
that uniquely identifies said buyer a<rthe registered holder of said virtual payment 
account. 

22. The method of Claim 21 , further comprising: in response to receiving 
application data from said buyer, determining an identify score for said buyer based 
upon said application data; determining whether said identify score exceeds a 
threshold identity score; and in response to determining that said identity score 
exceeds said threshold identity score, then proceeding to determining a credit score. 
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23. The method of Claim 22, wherein determining an identity score for 
said buyer comprises: requesting identity information from an identity bureau based 
on said application data; receiving said identity information from said identity 
bureau; and combining said identity information with said application data to 
determine said identity score for said buyer. 

24. The method of Claim 22, wherein determining an identity score for 
said buyer comprises requesting said identity score from an identity bureau based on 
said application data. 

25. The method of Claim 21 further comprising generating a public key 
encryption pair having a private key and a public key. 

26. The method of Claim 25, wherein installing a digital certificate further 
comprises transmitting said public key to said commerce gateway, said commerce 
gateway certifying said public key to generate said digital certificate; and receiving 
said digital certificate from said commerce gateway. 

27. The method of Claim 21 , wherein installing a digital certificate further 
comprises storing said certificate on a secure token. 

28. The method of Claim 21, further comprising: in response to 
determining that said credit score does not exceed said threshold credit score, 
establishing a prepaid virtual payment account associated with said buyer at said 
commerce gateway. 

29. The method of Claim 21 .wherein determining a credit score for said 
buyer comprises: requesting credit information for said buyer from a credit bureau 
based on said application data; receiving said credit information from said credit 
bureau; and combining said credit information with said application data to determine 
said credit score for said buyer. 

30. The method of Claim 2 1 , wherein said buyer comprises a business. 

31. The method of Claim 2 1 , wherein reward points associated with said 
virtual payment account may accrue based upon a volume of purchases charged to 
said virtual payment account. 
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32. The method of Claim 21, wherein said virtual payment account 
comprises a main account and at least one sub-account created by said buyer. 

«.-«•- • 

33. The method of Claim 32, wherein said buyer may set spending limits 
for said sub-account. 

34. The method of Claim 32, wherein said sub-account may be associated 
with a second buyer. 

35. The method of Claim 32, wherein said sub-account may be configured 
by said buyer to accept charges only from a predetermined list of sellers. 

36. A method for settling at least one virtual payment account transaction, 
the method comprising: 

receiving at least one settlement transaction request from a seller computer; 
determining that said at least one settlement transaction request is 
permissible; 

in response to determining that said at least one settlement transaction request 
is permissible, processing said at least one settlement transaction request; 

in response to processing said at least one transaction request, adjust a seller 
account associated with said seller computer. 

37. The method of Claim 36, wherein said at least one settlement 
transaction request is substantially contemporaneous with at least one associated 
purchase transaction. 

38. The method of Claim 36, wherein said at least one settlement 
transaction request is delayed for a predetermined period of time after at least one 
associated purchase transaction. 

39. A method for refunding a purchase transaction to a virtual payment 
account, the method comprising: 

receivings refund request from an administrative computer; 
in response to said refund request determining that said refund is permissible; 
in response to determining that said refund is permissible, processing said 
refund request; 
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adjusting said virtual payment account in response to the processed refund 
request. 

40. A method lor generating a report comprising receiving a report request 
from a seller computer using a virtual payment account; 

in response to said report request, determining whether said seller computer is 
associated with said virtual payment account; 

in response to determining that said seller computer is associated with said 
virtual payment account, generating a report; and 

transmitting said report to said seller computer. 

41. The method of Claim 40, wherein determining whether said seller 
computer is associated with said virtual payment account comprises: transmitting an 
authentication request comprising a digital certificate from said seller computer to a 
commerce gateway; determining at said commerce gateway whether said virtual 
payment account is valid; determining at said commerce gateway whether said virtual 
payment account is associated with said seller computer; and transmitting an account 
identification container comprising said digital certificate to said seller computer in 
response to determining that said seller computer is associated with a valid virtual 
payment account. 

42. A system for purchasing a product, comprising: 

a buyer computer operative to purchase a product using a virtual payment 
account; and 

a seller computer operative to receive a request from said buyer computer to 
purchase said product from said seller computer using said virtual payment account; 

in response to said purchase request, determine whether said buyer computer 
is associated with said virtual payment account; 

in response to determining that said buyer computer is associated with said 
virtual payment account, applying a cost of said product to said virtual payment 
account; and 

provide said product to a buyer associated with said buyer computer. 

43. The system of Claim 42, further comprising: 

a secure token associated with said buyer computer; and 
said seller computer is further operative to: 
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determine whether said buyer computer is associated with said virtual 
payment account by retrieving a digital certificate from said secure token; and 
transmit an authentication request including said digital certificate to a commerce 
gateway; and 

said commerce gateway is operative to: 

determine whether said virtual payment account is valid; 

determine whether said virtual payment account is associated with said buyer 
computer; 

and transmit an account identification container to said buyer computer in 
response to determining that said buyer computer is associated with a valid virtual 
payment account. 

44. The system of Claim 42, further comprising a commerce gateway 
operative to determine whether said buyer computer is associated with said virtual 
payment account by receiving an alternate authentication request from said buyer 
computer; sending an alternate authentication message from said commerce gateway 
to a buyer authentication device; receiving a verification request comprising said 
alternate authentication message; verifying said alternate authentication message with 
said commerce gateway; and in response to verifying said alternate authentication 
message determining that said buyer computer is associated with said virtual payment 
account. 

45. The system of Claim 42, further comprising a commerce gateway 
operative to: apply a cost of said product to said virtual payment account also: 
receiving an account identification container associated with said virtual payment 
account and said cost of said product from said seller computer; determining whether 
said virtual payment account may be charged for said cost of said product; and in 
response to determining that said virtual payment account may be charged for said 
cost of said product transmitting a valid transaction authorization from said 
commerce gateway to said seller computer. 

46. A system for purchasing a product, comprising: 

a buyer computer operative to purchase a product using a virtual payment 
account; and 

a seller computer operative to: 
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receive a request from said buyer computer to purchase said product, said 
purchase request identifying said virtual payment account as a payment source for 
said product; and 

a commerce gateway operative to: 

receive an authentication request from said buyer computer; 

determine whether said virtual payment account is associated with said buyer 
computer; 

transmit an account identification container to said buyer computer in 
response to determining that said buyer computer is associated with a valid virtual 
payment account; 

receive a processed purchase request from said seller computer; 

determine whether said virtual payment account may be used to pay for said 
product; 

in response to determining that said virtual payment account may be used to 
pay for said product, transmit a valid transaction authorization to said seller 
computer; 

charging said virtual payment account for a cost associated with said product. 

47. A system for creating a virtual payment account for a buyer, the 
system comprising: 

a commerce gateway operative to: 
receive application data from said buyer; 

determine a credit score for said buyer based upon said application data; 

determine whether said credit score exceeds a threshold credit score; 

in response to determining that said credit score exceeds said threshold credit 
score, establish a virtual payment account associated with said buyer; and 

install a digital certificate on a buyer computer associated with said buyer that 
uniquely identifies said buyer as the registered holder of said virtual payment 
account. 

48. The system of Claim 47, wherein said commerce gateway is further 
operative to: in response to receiving said application data from said buyer, determine 
an identify score for said buyer based upon said application data; determine whether 
said identify score exceed a threshold identity score; and in response to determining 
that said identity score exceeds said threshold identity score, then proceeding to 
determine a credit score. 
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49. The system of Claim 47, wherein said buyer computer is further 
operative to install a digital certificate by generating a public key encryption pair 
having a private key and a public key; transmit said public key to said commerce 
gateway; and wherein said commerce gateway is further operative to certify said 
public key to generate said digital certificate; and transmit said digital certificate to 
said buyer computer for storage. 

50. A system for settling at a virtual payment account transaction, 
comprising: 

a commerce gate way operative to: 

receive a settlement transaction request from a seller computer; 

determine whether said settlement transaction request is permissible; 

in response to determining that said at least one settlement transaction request 
is permissible, process said at least one settlement transaction request; 

in response to processing said at least one transaction request, adjust a seller 
account associated with said seller computer. 

51. A computer-readable medium having an executable component, for 
purchasing a product from a seller computer using a virtual payment account, 
wherein the executable component purchases a product by: 

receiving a request from a buyer computer to purchase said product from said 
seller computer using said virtual payment account; 

in response to said purchase request, determining whether said buyer 
computer is associated with said virtual payment account; 

in response to determining that said buyer computer is associated with said 
virtual payment account, applying a cost of said product to said virtual payment 
account; and 

providing said product to a buyer associated with said buyer computer. 

52. The computer-readable medium of Claim 51, wherein the executable 
component purchases a product by further determining whether said buyer computer 
is associated with said virtual payment account comprises: retrieving a digital 
certificate from said secure token; transmitting an authentication request including 
said digital certificate from said buyer computer to a commerce gateway; determining 
at said commerce gateway whether said virtual payment account is valid; determining 
at said commerce gateway whether said virtual payment account is associated with 
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said buyer computer; and transmitting ah account identification container to said 
buyer computer in response to determining that said buyer computer is associated 
with a valid virtual payment account. 

53. The computer-readable medium of Claim 5 1 , wherein the executable 
component purchases a product by further determining whether said buyer computer 
»s associated with said virtual payment account comprises: transmitting an alternate 
authentication request from said buyer computer to a commerce gateway; sending an 
alternate authentication message from said commerce gateway to a buyer 
authentication device; retrieving said alternate authentication message; verifying said 
alternate authentication message with said commerce gateway; and in response to 
venfymg sa,d alternate authentication message determining that said buyer computer 
is associated with said virtual payment account. 

54. The computer-readable medium of Claim 5 1 , wherein the executable 
component purchases a product by further applying a cost of said product to said 
virtual payment account comprises: receiving said account identification container at 
sa,d seller computer; transmitting said account identification container and said cost 
of said product from said seller computer to said commerce gateway; determining 
whether said virtual payment account may be charged for said cost of said product- 
and in response to determining that said virtual payment account may be charged for 
sa,d cost of said product, transmitting a valid transaction authorization from said 
commerce gateway to said seJ Ier computer. 

55. A computer-readable medium having an executable component for 

computer using a virtual payment account 
associated with a buyer computer, wherein the executable component purchases a 
product by: 

receiving a request from said buyer computer to purchase said product said 
purchase request identifying said virtual payment account as a payment source for 
said product; 

in response to said purchase request, transmitting an authentication request 
from said buyer computer to a commerce gateway; 

determining at said commerce gateway whether said virtual payment account 
is associated with said buyer computer; 
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transmitting an account identification container to said buyer computer in 
response to determining that said buyer computer is associated with a valid virtual 
payment account; 

transmitting said purchase request including said account identification 
container from said buyer computer to said seller computer; 

transmitting said purchase request from said seller computer to said 
commerce gateway; 

receiving said purchase request at said commerce gateway and determining 
whether said virtual payment account may be used to pay for said product- 

in response to determining that said virtual payment account may be used to 
pay for said product, transmitting a valid transaction authorization from said 
commerce gateway to said seller computer and said buyer computer; 

charging said virtual payment account for a cost associated with said product- 
and * 

providing said product to a buyer associated with said buyer computer. 

56. A computer-readable medium having an executable component for 
creating a virtual payment account for a buyer which may be used to pay for products 
ordered over an internetwork, wherein the executable component creates a virtual 
payment account by: 

receiving application data from said buyer; 

determining a credit score for said buyer based upon said application data- 
determining whether said credit score exceeds a threshold credit score- 
in response to determining that said credit score exceeds said threshold credit 

score, establishing a virtual payment account associated with said buyer at a 

commerce gateway; and 

installing a digital certificate on a buyer computer associated with said buyer 
that uniquely identifies said buyer as the registered holder of said virtual payment 
account. 

57. The computer-readable medium of Claim 56, wherein the executable 
component creates a virtual payment account by further receiving application data 
from said buyer and in response, determining an identify score for said buyer based 
upon sa,d application data; determining whether said identify score exceeds a 
threshold identity score; and in response to determining that said identity score 
exceeds said threshold identity scored then proceeding to determining a credit score 
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58. A computer-readable medium having an executable component for 
settling at least one virtual payment account transaction, wherein the executable 
component settles at least one virtual payment account by: 

receiving at least one settlement transaction request from a seller computer; 

determining that said at least one settlement transaction request is 
permissible; 

in response to determining that said at least one settlement transaction request 
is permissible, processing said at least one settlement transaction request; and 

in response to processing said at least one transaction request, adjust a seller 
account associated with said seller computer. 
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113 



\SAVE CERTIFICATE 



114 



128 
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?!.^5 ccunl Application . Net:cape 

* ~- V"> .vy;.'.- ^'Vvrr-u^jFT "~ - 




Thank you for your interest m e Charge 
/ust 10 to 15 minutes. * KtoQlt yw * °^ 3f 10 ™* «*« process tafc 



There are four easy steps: 

1. Provide your information 

2. Application review & results 

3. Download 

4. Activate your account 

Before you start 

We recommend that you: 

* Gather your employment and banking information which »n„u r>o~r .„ 

•**»*-* co^e. ^ ,„„,?„. sircar appfica,i - 

Choose your Net Account 

° &£5S,ESKSSS£r — — — - - 
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5r eChajge Net Account Application • Netscape 



Step 1 : Provide your Information 

Electronic disclosure agreement 

Please read this document carefully and keep a copy for your records. 

Well provide the toBcrwmg information to you electronically, as required by the Truth in Lending Act 

* Terms and conditions of your eCharge credit account 

* Monthly statements 

* Change in terms notices 

* Initial Disclosure Statement 

Electronic disclosure statements are available at htto /Avww erh aroe com/riisr In* ^ am 
good for at least 90 days. After the 90 day period, the disclosure information wHI be available upon 
request by contacting Customer Support,, Any changes to these statements win provided to you 
electronically at your email address on We. In the future, we may provide additional disclosures 
electronically To recerve this information youll need a 128-bit browser that rs JavaScript enabled 
and connection to the Internet. 

To continue your application you need to check all boxes and agree to accept electronic 
disclosures. 

D I have access to a computer that satisfies the above requirements. 

(You a/e cumntfy using a computer that satisfies these requirements) 

D I have access to a printer OR can download information to keep copies for my records. 

D I want to complete this credit application and I agree to accept electronic disclosures of the 
information listed above. 

For assistance concerning these disclosuies. requesting technical information or updatmq vour 
email address, contact us at Customer Sup port 
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| SreChaige Wet Account Application • Netscape 




Step 1 : Provide your Information 

Apply for a credit account 



AH folds marked with a star (") must be completed to we can process yow eCharge Net Account 
application. For an explanation of the required information, cfck on a specific W>k or Help. 



Personal information 



Current address 

i 



I — 



Twit »TtM» »«d»r^ 



F manrial and employment information 



I- ^^h. g| 




610 



Making payments 

You can pay for your credit account purchases bom your checking or 
savings account. 

fi'wlinr e Checking O Savings 



ABA p»»tm» Nmnfe«l» |T 



3 



Special offers 

© Please send me notices about special offers from eCharge. 
online rriafers who accept eCharge. and other companies. 
O Please send mo special ofler notices only from eCharge. 

O Please do not send me special offer notices from eCharge or any 
other company at this time. 
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£T- eChaiQe Net Account Applicaticn - Nettcap; 




e<^arge 




fl^ 1 3 4 



Step 1: Provide your Information 

Review account appbcaion 



Please check the application information below foi accuracy 



Personal Information 
Fast Nam*" 
Mrddle MiW 
Last Name* 
E-Mail Address* 
DareofBaib* 
Home Phone* 
Daytime Phone 

Current eddiess 

Address* 

City- . 

State* 

Zip Code* 

Home Ownership" 

Time at this Address* 



Financial and •mptoymrnt Information 

Social Security Number 

Employment Status* 

Time si Current Employment* 

Annual Household Income* 



Terry 
H 

Smith 

Ierrys@echar9e.c0m 
07 / 17 / 1?47 
12*4567090 
17*4567890 



123 Main Street 
New Yd* 
NY 



MM I 



Bank account Information 
Account Type* 
ABA Routing Number 
Bank Account Number 



Own 

ID years 03 months 



111-22 3333 
Employed 

OS years 05 months 
IS0BD0 to J99J999 



Checking 
111111111 



Special offers 

Please send me notices about special oflers kora eCharge. online retailers who accept eCharg*. and other 
companies. 

leans end Conditions 




I understand thai I am applying lot credit and. * appro**, my erode account w* be gowjmod by th« Term* and 
Condbons. I bawp read the Terms and Condemns r egard ing tfes credH account arid everything I have stated m my 
aopiration b true. By ckcking on th» 1 Agree* button below, I agree to the Terms and Conditions and 
acknowledge that 1 ha— downloaded or prirtod a copy of those Terms and Ccndfrions tor my records. By cftung on 
the 1 Agree* button below, t also acWwfcdgo that l here renewed the Stale Law Disclosures and lauthon>« th» 
Bank to obtain a cred* report and to check my credit and employment history. 



tw- 
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I eChaige Net Accounl Application - Netscape 




1* 

ex^iarge- 




ten 



Step 2 : Application Review & Results 
Congratulations! 

YbuVe been approved for an eCharge Net Account. Here are Ihe terms for your credit account: 

Credit limit % 

Introductory APR 

APR after Introductory Period 



% until |date} 



These important disclosures are part of the Terms and Conditions of your eCharge Net 
Account. You should print or download a copy of these disclosures for your records. For a 
detailed explanation of your introductory APR or post- introductory APR please review the 
Terms and Conditions . 

By clicking on the "I Accept" button below. I agree to the terms set forth above. 



i do hoi Acccr>i > 



® 2000 ?i Kji-a- •! ~t vol ! :•».. AH lipbte t***r»*4. 



Q-*7 Aapwc 9tiwt 



_/ 



is;.©,- 



it ■ «•* 
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£f eChaige Nel Account Application • Nstscase 




^NET AC£DUJ!0L 



Step 3: Download 

eCharge is downloading the security software 

I! wiB take approximately X minutes to download the security software on a 56 6 kbps modem 

connection Thank you for waiting. 

This security software contains our proprietary encryption technology, along with other unique security 
features. So anytime you make an eCharge purchase, you can count on guaranteed fraud protection. 

You can make purchases with your eCharge Net Account as soon as thrs download is complete and 
you have activated your Digital ID. 
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■ j*jeChaige Nel Account Application • Netscape 



:3*ET ACCOU/OL 



5 Ste;s 



Step 4: Activate Your Account 

Activate your Digital ID 

eCharge's security starts with a unique digital certificate, which stays on your computer This 
digital certificate, combined with your Pas* Phrase, makes up your Digital ID. "To activate your 
Digital ID. follow these simple steps: 

Digital ID Name: 



Security Pass-Phrase: 



Confirm Pass-Phrase: 



Enter the name you'd bke to use to identify yourselj to 
eCharge. Example: Bobs ID 

Youi Pass-Phrase should be something youll remember 
and no one eke can figure out. Your Pass- Phrase must be. 

• at least 1? characters long 

• include at least one capital letter 

• one lower-case letter 

• one punctuation mark 

• and one number 

Example: My dog Skip weighs tS pounds. 



Re-type your Pass- Phrase. 



Security Question: 



j Enter a question that will help you remember your 

- Pass-Phrase. Example: How much does my dog weigh? 



This Digital ID will constitute your signature for purposes of accepting the Terms and 
Contritions of your Account, as woll as fot making future purchases with your e Charge 
Net Account This Digital ID has the same legal force and effect as your physical 
signature. By clicking the Activate button, you agree to these terms, as well as the 
Terms and Conditions of the Agreement 
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eChaige - Account Centet - Netscape 




Ycpf^ccccht. v.t AcwuTrt Dctaiis *if Statements Y Pa^cnU&.Ft^ding, 



View or change your account Information 



Choose Accoun! : [Terry Smith gj 



To change your account information, enter the new information aod click Update. Alt fields marked 
with a star Q must be completed 



Name of Account Holder 
Account 

Type of Account 
Credit Lrmrt 

Personal Infoimation 

E-Mail Address * 

Address * 

CitV* 

p— " 

" I ■ -t 1 .. — . ■ - ' ■ -. ■ 



Terry Smith 



Credit 
15.000 



Home Phone" Daytime Phone 

|l23^BQ.7eO 0 \ I* " 



3 



J 



SU1£" 



□13 



Zip Code " 



Special offers: 

G Please send me notices about special offers from eCharge, online retailers who accept 
eCharge. and other companies. 

O Please send me special offer notices only from eCharge. 

O Please do not send me special offer notices from eCharge or any other company at this 

/ 



time 
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j 5t eChatge - Account Cer.tei • Netscape 

! - *•- - - i T . • t 



"U4»*. .... . 




VcsrAccoynt. ~f Aecoynt Octalls ^f. Statements,." PapTscnts a-.F^tfin^ 



Change your Pass-Phrase 

For your security and convenience, you can change your Pass-Phrase at any time 
Just select your Digital ID and rtH in the information below. 



Mortal ID : 



Select Digital ID- jg 



Old Pass-Phrase : 



[ 



New Security Question : 



New Pass Phrase : 



3 



Re-enter New Pass Phrase: 




] 



CAHCtl 
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5- eChatge • Acccur.l Cer.tet • Netscape 



EES 



e<^arge- 



Aeeo:iM 



nil Accmmt: 



rfijrr<a,cccpr.t.; ; f Acscvnt Detail* ^fJ.tyegtc/.tfc ^P^jr.cris & fs*i}fi$' : 



Create a Sub Account 

You can trrale up to bve secure Sub Accounts A no change, gmmj everyone in your tomSy a 
separate account, Or set up Sub Accounts to* specific types of puic bases. Each Sub 
Account also offers parental controls, which let you set purchasing bmrts lor the kids and 
restrict the web sites from which they can purchase. 

F or security reasons,, each account holder is assigned a personal Digital ID and Pass- Phrase. 
As the primary r Charge Net Account holder, you're liable lor aO chaiges incurred by the Sub 
Account holders. If you need more than foe Sub Accounts, you can create additional 
accounts for a smafi lee. F or details, please contact Customer Supp or t 

A* 6eWs marked with a star f) must be completed before we can create your Sub Account. 

Sub Ac c ount Information 

Type of Account* 

** Credit - This account allows you to shares the credit fcmit of your primary account. 

C Prepay - Purchases are automatically deducted bom your pre-paid balance and you can 
add lands as often »s you Mte to this Sub Account. 
Account Holder Firs! Name ' I f 
Account Holder last Name * 
AcifiMPT 

E-Mail Arfdrm* 1 ~ I 

Set parental controls 
Perchesing limits 

To set purchasing femes for this Sub Account. Ul in one or more ol the following options. 
Single Transition 

Monthly Total 



L 



J 



3 



J 



J (number of transactions) 



Web site t estrlctfora 

To set purchasing bmits on specific web sees, simply type in the monthly dollar amount tor 
each Retail Category . You can also rest net the Retail Categories fcom which your children can 
make purchases by checking the categories you want to restrict. 

Monthly 



Cnet >L 
DVD Express 
MP3.com } |[ 



3 



3 



3 



D 

D 
D 



Special ofiors 

C* Please send me notice* about 
eC barge, and rthet companies. 
O Please send me special otter notices only fcom 
C Please do not send me special 
time. 



special ©Sent bom eCharge. online retailers who accept 



eChargo. 

bom eCfcarge or any or her company at this 



PLEASE NOTTr. Tbese settings apply only to this Sub Account You can change these 
settings at any time. 



CJMCfk 
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Fig.9C. 
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SreChaige Net Account Applicalicn • Netscape 



Primary Account Statement 

09/12/1999 104)9/1999 
Qedrt Activity Summary 




previous Balance [ [. 


948.33 




-1 


82300 




898.33 






0.00 






0.00 


^tHANCE CHARGE . . 




2J0O 


L» — ^ - w\-^ % — . 


h 


S75JJD 




i 


48JJ0 



Errors Of disputes must be reported in accordance with the Fair C»frd»t Bilfanq Act 



Transactions foi Terry Smith 

":.r*o....j c-.f- ; 
08/12/1999 09/12/1999 324583867 
08/15/1999 09/150999 324583857 
09/17/1999 09/17/1999 3245838G7 



Transactions foi Chris Smith 



T.S-: 



www.cdnow com 
www , ama 7 on c om 
w»w ehaycom 

Total: 
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} SrcChaige • Account Center • Netscape 



Ho** I H»lp I S*c«rtty | lo f o.t 




i 



1 



Mil ACCOUW I - ?| 



SH'»w»»»S | Real-Ti.T.* Trjr.:jel:or.» 



View real-time transactions 



Below are lians actions posted since your last si Yemeni; 



Terry Smith - Credit 



084)1/1999 08*)1/1999 Payment received 



Chris Smith .Credit 



Available Balance $2,314 



$100 00 



08/1 </1 999 08/12/1999 wDNny.JCrew.com 



$3895 



Available FUnds $500.00 



0&01/1999 0801/1999 Funding receded $50000 



Kfmmle Smith .Prena 



Available Funds $30.01 



Pending 08/17/1999 



w»»wf.eToYs.com 



$69.99 



/ 
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634 



634 



634 
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Fig.lOC. 
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Fig.UA. 



* 



WO 00/79452 



PCT/USOO/16669 



22/56 



1155 



; & Virtual Store - Netscape 

, Fue Edit View Go gewnuricalof 




1160 



RTUAL STORE 



Order Form 



Quantity Description Amount 
1 WtualStorBPC $449j0O 
1 2 day Sfrifjpno, $10.95 
Total $459.95 



Payment lype [eCharge 
At count # | 



Expiry Date |nn/TT | 
Name on Card { ~~" 
B&ng Address | 
Oty | 



State | | 
ZtpCQde P 



3 



1165 




haso 



1150 



1172 
1175 

1177 



Buy the Wwld. 



] 




SJeCHARGE - Netscape 




EJUS 



e<^iarge\fp 



jpSefecEDIgl taEfPI 



DIGITAL ID: 

l~Setecf Digflal tD- jj§ 



PASS PHRASE: 



CONTINUE 



CANCEL J 



F orpot Ycwr P tssr Phrase? 



1170 



Fi^.UB 



♦ V 
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eCHARGE - Netscape 



e<^arge 



Help/ FAQ | Customer Support 





Your Purchase 



FROM ACCOUNT: 



{Terry's Credit 



5 



02 / 25/2000 




Qtry. 
1 



Ite» Price ej. 

Evolution Ski 31 icJtrocJt TcleuaxJi SJtis $430.00 

Puaa H19K Octane II Running Shoes $44.00 

Coloz h: Site: 5.5 v ; V; 

Dxmlop Grand Prix Trtanixu* Tennis '. Ba.. . $10; 00 
Subtotal 

Shipp in<? ' * 



Total 
$430.00 
$44.00 

$20.00 
v$ 4^4.00 




I authorize eCharge Corporation 

to x>o< xxxxxx xxxx xx 



Prtnt Dauiis 



AUTHORIZE 



CANCEL 



1180 
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eCHARGE •* Netscape 




Help/FAQ | Customer Support 



echarge" ^ ■■■■ 



Thank you for using eCharge, 
the secure way to buy online. 



TRANSACTION 
COMPLETED 



CLOSE 




1185 



Fig.llD. 
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Thank you for ytxr purchase. Your purchase wiB be delivered to you n 2 days, 
„ .i 

Referencef : W12003 

Item Purchased: Virtual Store PC 

Paidby:eCHARGE 

SJVp to: 123 Oak Street, Vancouver, WA 99999 
7radcng#: 32741613 

If you have any questions, p tease contact 
us at customer semcegfrvrtual storexom . 
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START ORDERING VIA WEB BROWSER 



I 



ESTABLISH SECURE CONNECTION TO 
COMMERCE GATEWAY WEB SERVER 



I 



RUN BUYER AUTHENT1CAT0R 

(Tig. 13) 





227 



DISPLAY BUYER 
AUTHENTICATION 
ERROR MESSAGE 



DISPLAY VPA SELECTION WEB PAGE 



I 



COLLECT SUB-ACCOUNT 
1NT0RMATI0N FROM BUYER 



I 




228 



230 



232 



SEND SUB-ACCOUNT AND 
AUTHENTICATION CONTAINER TO 
ACCOUNT ID CONTAINER GENERATOR 

(Fig. 17) 



I 



RECEIVE ACCOUNT ID CONTAINER FROM 
COMMERCE GATEWAY 




234 



OBTAIN PURCHASE CONFIRMATION 
FROM BUYER AND SEND PURCHASE 

REQUEST WITH ACCOUNT ID 
CONTAINER TO COMMERCE ENGINE 

(Fig. 18) 



238 



RECEIVE PURCHASE REQUEST RESPONSE 
FROM COMMERCE ENGINE 



DISPLAY ORDER CONT1RMATION SCREEN 




240 



241 



DONE 



> 



242 



Fig. 12 
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( START BUYER 
\AUTHENTl CAT OR 

I 
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244 



RECEIVE 
AUTHENTICATION 
REQUEST AND 
CONTAINER 
FROM WEB 
BROWSER 





INSERT 
CERTIFICATE ID 
INTO 
AUTHENTICATION 
CONTAINER 

I 



RETURN 
AUTHENTICATION 
REQUEST AND 
CONTAINER TO 
WEB BROWSER 



250 




GENERATE 
ALTERNATE 
AUTHORIZATION 
SCREEN 
(Fig.14.) 

I 





APPLY FOR A 






VIRTUAL 






PAYMENT 






ACCOUNT 






iFig.lS.) 





DETERMINE 
AUTHENTICATION 

STATUS AND 
RETURN IT TO WEB 
BROWSER 



262 




RETURN 





256 



261 



RETURN 
UNSUCCESSFUL 
AUTHORIZATION 
TO WEB BROWSER 



Fig. 23. 
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START ALTERNATE 
AUTHORIZATION 




DISPLAY AUTHORIZATION 
OPTIONS 



1401 



REQUEST 
AUTHORIZATION 
CODE? 



1410 



DISPLAY CODE ENTRY 
AUTHORIZATION FORM ON 

BROWSER 



WEB 



I 



SEND AUTHORIZATION CODE TO 
BUYER'S AUTHENTICATION 

DEVICE 



BUYER COMPLETES CODE ENTRY 
AUTHORIZATION FORM ON WEB 

BROWSER 



I 



TRANSMIT A UTHOR1ZATION 
FORM TO COMMERCE GATEWAY 



1405 



No 



1415 



1420 



1425 



1430 



DISPLAY 
INTERACTIVE 
AUTHENTICATION 
FORM ON WEB 
BROWSER 



r 



1450 



BUYER COMPLETES 

INTERACTIVE 
AUTHORIZATION 
FORM ON WEB 
BROWSER 



1455 





1499 



RETURN UNSUCCESSFULL 
AUTHORIZATION 




RETURN SUCCESSTULL 
AUTHORIZATION 



1498 



Fig. 14 
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('START APPLYING FOR A 
VIRTUAL PAYMENT ACCOUNT 
VIA WEB BROWSER 

1 



RECEIVE REQUEST FOR 
APPLICATION FORM 



I 
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273 



SEND REQUEST FOR 
APPLICATION FORM TO 
COMMERCE GATEWAY WEB 
SERVER 



I 



260 



274 



RECEIVE AND DISPLAY 
APPLICATION FORM FROM 
COMMERCE GATEWAY WEB 
SERVER 



I 



SEND COMPLETED ACCOUNT 
APPLICATION FORM TO 
ENROLLMENT SERVER 
(Ftg.U.) 




275 



266 




265 



No — ► 



GENERATE KEYPA1R ON BUYER 
COMPUTER AND SUBMIT PUBLIC 
KEY TO ENROLLMENT SERVER 



I 



267 



RECEIVE AND 
DISPLAY 
UNSUCCESSFUL 
APPLICATION 
RESULT PAGE 

FROM 
ENROLLMENT 
SERVER 



276 



RECEIVE AND DISPLAY 
SUCCESSFUL APPLICATION 
RESULT PAGE FROM 
ENROLLMENT SERVER 



RECEIVE DIGITAL CERTIFICATE 
FROM ENROLLMENT SERVER 



c 



DONE 




278 



Fig, 15 
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START ENROLLMENT 



I 



RECEIVE COMPLETED 
APPLICATION FROM 
BUYER COMPUTER 



I 



REQUEST 
INFORMATION FROM 
ID BUREAU 
(Fig.27.) 




30156 




REQUEST 
INFORMATION FROM 
CREDIT BUREAU VIA 
CREDIT PROCESSING 
SERVER ADAPTER 
(Fig.21.) 



285 



SCORE APPLICATION 
BASED ON ID BUREAU 
AND CREDIT BUREAU 
INFORMATION AND 
INTERNAL CRITERIA 



286 




RETURN SUCCESSFUL 
ENROLLMENT 



289 



RETURN UNSUCCESSFUL 
ENROLLMENT 



Fig. 16. 
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START ACCOUNT ID 
CONTAINER GENERATOR 



I 




RECEIVE SUB-ACCOUNT, AND 
AUTHENTICATION CONTAINER 
FROM WEB BROWSER 



DETERMINE INTERNAL 
ACCOUNT ID ASSOCIATED 
WITH AUTHENTICATION 
CONTAINER 



CREATE EMPTY ACCOUNT 
IDENTIFICATION CONTAINER 



ADD INTERNAL ACCOUNT 
IDENTIFICATION AND SUB- 
ACCOUNT INFORMATION TO 
EMPTY ACCOUNT ID 
CONTAINER 



APPLY INTERNAL DIGITAL 
SIGNATURE TO ACCOUNT ID 
CONTAINER 



RETURN ACCOUNT 
IDENTIFICATION CONTAINER 
TO WEB BROWSER 



c 



I 



RETURN 



800 



802 




804 



806 



808 



810 



'812 



814 



Fig .17. 
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START COMMERCE ENGINE 



I 




RECEIVE REQUEST AND ACCOUNT 
IDENTIFICATION CONTAINER 
FROM WEB BROWSER 



300 



302 



304 



75 



316 



FORWARD 
REQUEST TO THE 
COMMERCE GATEWAY^ 
ADAPTER? 



Yes 



1 



FORWARD REQUEST TO 
COMMERCE GATEWAY 
ADAPTER 
iFig.19.) 



1 



RECEIVE RESPONSE FROM 
COMMERCE GATEWAY ADAPTER 



SHIP AUTHORIZED PRODUCT 



I 



SEND SETTLEMENT REQUEST TO 
COMMERCE GATEWAY 



I 



SEND RESPONSE TO WEB 
BROWSER 



c 



I 



RETURN 



> 



No 



306 



308 



PERFORM 
TRADITIONAL 
AUTHORIZATION 

I 



318 



SHIP AUTHORIZED 
PRODUCT 

I 




310 



SEND SETTLEMENT 
REQUEST TO 
TRADITIONAL CREDIT 
PROVIDER 

i 



f 



320 



322 



SEND RESPONSE TO 
WEB BROWSER 



312 



314 



324 



Fig.18. 
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START COMMERCE 
GATEWAY ADAPTER 



I 




330 



332 



RECEIVE REQUEST AND 
ACCOUNT IDENTIFICATION 
CONTAINER FROM COMMERCE 

ENGINE 



I 



SEND REQUEST AND 
ACCOUNT IDENTIFICATION 
CONTAINER TO 
TRANSACTION SERVER 
(Fig.W.) 



I 



RECEIVE RESPONSE FROM 
TRANSACTION SERVER 



FORMAT RESPONSE 
INCLUDING TRANSACTION 
STATUS FOR COMMERCE 
ENGINE 



FORWARD FORMATTED 
RESPONSE TO COMMERCE 
ENGINE 



c 



I 



RETURN 




334 



336 



338 



Fig.19. 
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(start transaction server 

T 

RECEIVE TRANSACTION REQUEST 

I 





DECODE AND VERITY ACCOUNT 
IDENTIFICATION CONTAINER 
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